之前的工作筆記在公司電腦上，因此這裏就先來淺談下NSURLProtocol做web緩存時令人印象深刻的坑吧！
1、使用的是UIWeb和WKWeb的區別：
UIWeb就比較簡單了，隨便網上搜下就能找到NSURLProtol使用方法，按上邊的做就行；
WKWeb就有點麻煩了，因爲和UIWeb不一樣，wk需要做些特殊的設置，才能攔截到https和http請求（待完善）；
2、對於post請求的處理：
nsurprotocol能攔截到post和get請求，但是攔截到的post請求的請求體httpbody會丟失（ui和wk都有此毛病；攔截原生請求是否會丟失呢？ 曾經在公司電腦上嘗試過，待完善）（httpbody被蘋果優化掉了）；這就會出現很多問題
例如問題一：所有我們要想對post請求重定向就比較麻煩了：（注：post請求參數是設置在httpbody中的，protocol攔截拿不到參數）
例如問題二：即攔截到post請求不做處理，只處理get請求也會影響post請求的發送：
在canonoirequet方法返回no也會影響post請求的發送，可能也是因爲httpbody的問題，我用我們的app親測過，加上nsurlprotol攔截後（即使不處理post請求）和不加nsurlprotol攔截，發現h5頁面的展示的內容不同（攔截展示的敬請期待，而不攔截展示的是正常白領好物頁，在網絡通暢情況下多次測試均能復現）。
我最進做的一個需求就是攔截神策的請求（js神策都是get請求）統一distictid爲原生的，將其js參數distictid轉換成原生的distictid值，想用攔截的方式處理，這樣會影響其他js的post請求發送。最終我們選擇用交互的方式處理這個需求。
解決方法：
1》將httpbody的內容放到httphead中，在我們用protocol攔截到post請求時，將httphead的相關參數添加的httpbody中，將請求發出去，需要h5的同學設置httphead。
2》與h5的同學約定其他非http或https的自定義協議（也就是原生和js交互的原理了），用交互的方式將js的post請求放在原生端去發送，再將請求數據返回給原生。
所以，如果真想用protol攔截js請求的話，那就選擇交互的方式，將所有post請求讓原生端發送吧。
3、多次網頁請求不執行protocol相關的代理方法：
如果代碼沒問題的情況下，在該執行相關方法時沒有執行，也是正常的情況，這時候就要考慮request時設置的是否是默認的cachepolicy了，如果設置的的默認cachepolicy則會有強制緩存和對比緩存了（詳見上一篇博客），所以有時候即使是返回200接口也不會發出去（對比緩存），請求都沒有真正發出去，自然是還沒走到protol攔截的過程了，所以方法就不會執行；
以上是protol攔截web請求，當然攔截到這些請求我能就能緩存數據了，下載方法不在此贅述了。
另外protocol攔截原生請求也是有坑的，且看下一篇博客