大半夜睡不著...
今天用node寫了返回客戶端請求資源的http服務，確實發現了一些以前沒注意到的問題。
第乙個是在接收到請求的時候，解析完路徑後，一定要判斷請求的檔案的字尾，以便選擇對應的content-type。
第二個是要確保請求資源的路徑正確。
我今天犯了乙個錯誤是，在這個單純返回請求資源的http服務中，當匹配不到資源時，返回index.html.
這就埋下了乙個隱患：
當我從index頁面通過location.href跳轉到b頁面時，由於判斷字尾的switch語句中漏了對.html型別的判斷，導致b頁面直接返回了index.html，而此時b頁面的路徑是/b.html。
而b頁面i拿到的ndex文件中的link標籤發起css請求時，請求的路徑在/b.html的基礎上變成了/b/css/b.css,正確的位址應該是/css/b.css。node程式因此丟擲錯誤而退出。
在除錯的過程中，我也梳理了node中常見的幾個路徑：
__dirname：被執行的js檔案所在資料夾；
__filename：被執行的js的絕對路徑。
process.cwd()：執行node命令時所在資料夾的絕對路徑。
同時也有前輩指出只有在require()時才使用相對路徑(./, ../) 的寫法。
參見：
node中的路徑解析
對於node中路徑的解析，常見的有兩種方式 一，根據路徑經行業務處理的應用是靜態檔案伺服器，可以根據路徑去查詢磁碟中的檔案 function req,res else 二，可以根據路徑來選擇控制器 如 control action a b c control為具體的控制器，action為具體的行為，...
461 幾個不同的ctags資訊梳理
全部學習彙總 近些年在編輯器上花費的時間太多了，尤其是emacs。靈活是好的，很自由。但是，太靈活了之後，也會出現一些選擇困難症。尤其是，預設的軟體包中不給我們那麼多的選擇的時候，哪怕是找到正確的那乙個都是麻煩的。我在幾個不同的電腦上遇到過ctags的問題了，windows上逐漸積累了一堆可執行檔案...
Java web 中幾個常用的獲取專案路徑的方法
request.getcontextpath request.getcontextpath 是為了解決相對路徑的問題，可返回站點的根路徑，即專案名稱。如果context中沒有配置path屬性，所以你的工程檔案就是在根目錄下，相當於path request.getcontextpath 獲得的值也就為...