1、接口被瀏覽器緩存，導致必須請求的接口沒有請求，使得邏輯出錯。
出現問題的情況是我們重定向到一個固定get類型的地址，發現有時接口會被調用，多半時候沒有被調用，多此排查後端代碼無果，只能懷疑到前端，查看瀏覽器重定向請求（chrom F12後勾選保存日誌選項）後發現接口是調用了的，實在是百思不得其解，後來發現這個重定向有個from disk的說明，當時沒注意，後來發現這就是從本地緩存拿結果的標緻，要想禁止緩存，不可能要求所有用戶設置F12後勾選禁止緩存，只能後端改造，後來發現可以在請求地址後面帶一個時間戳的參數，這樣瀏覽器認爲是不同請求就會進行網絡請求，而不是from disk。
2、URL和URI的區別
URI：uniform resource identifier 統一資源標識
URL：uniform resource locator 統一資源定位
URN：uniform resource name 統一資源名稱
url是一個特殊的uri，url獲取資源的描述，uri是資源標識，uri是個非常寬泛的概念，所以是個比較抽象的描述，類似萬金油。
3、url爲什麼要編碼？
a、
HTTP協議中定義了URL的書寫規範，protocol用://分割，path用/分割，第一個參數前用?分割，第二個參數開始用&分割，如果請求方的參數中含有這些分割字符，那麼服務方的解析程序無法按預期的方式解析，因爲他不知道你的分隔符到底是不是參數的一部分。所以需要對特殊字符進行編碼，目前提供的編碼函數基本都統一了，會有一批豁免的字符不用編碼，被編碼的都是這批豁免的字符之外的，中文就在被編碼的範疇內。
b、
知道爲什麼編碼後，還需要知道誰在編碼，誰在解碼。一般而言瀏覽器會對發出的請求檢查，發現不是ascii碼，就會進行編碼，這裏我們就不深入討論這點，因爲不同瀏覽器工作方式都不一樣，程序開發時不能依賴瀏覽器的URL編碼機制，所以我們需要自己手動編碼，對於Javascript而言，編碼函數有三個，豁免字符分別如下：
encodeURI（82個）：!#$&'()*+,/:;=?@-._~0-9a-zA-Z // 不會編碼 / &，所以可以對爭端URL編碼
encodeURIComponent（71個）：!'()*-._~0-9a-zA-Z // 會把 / ? &編碼掉，所以不能對整段URL編碼
escape（69個）：*/@+-._0-9a-zA-Z // 編碼字符更加廣泛，如果有特殊要求
c、
服務端處理編碼的方式也是需要我們知道的，以tomcat爲例，容器是會自動爲我們解碼的，tomcat解碼是以參數爲單位的，所以如果你url中含有中文或特殊字符，是需要編碼的。
d、
實際使用案例，前端請求接口參數是一段url，這個時候，前端的編碼方式需要使用encodeURIComponent這個參數，因爲你需要將& / ?這些字符也編碼，這樣服務端才能拿到這個參，然後解碼出來。
Java中的URLEncoder會對 / &進行編碼，所以這個函數不能對整個url編碼，否則就無法識別了。