之前的工作笔记在公司电脑上，因此这里就先来浅谈下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拦截原生请求也是有坑的，且看下一篇博客