WKWebView 报报了AJAX Error 之网络请求Header 丢失

      WKWebView 是苹果手机上主要的H5加载控件，它相比UIWebView 有诸多优势。在次不做比较，但是它的坑缺比较多。网上也有很多的例子但是做的比较好的真不多，我在这里推荐俩博客供大家参考。https://cloud.tencent.com/developer/article/1005691；https://segmentfault.com/a/1190000016883249 这两篇介绍的我们日常的碰到的坑，网上其他的篇章介绍的坑没有这两篇介绍的透彻，且有些坑还是自己给自己挖的。

     本篇介绍就是自己给自己挖坑的场景之一，也是当前网络上没有的坑--网络请求header 丢失。

     产生场景：在我们的WKWebView里加载一个具有VOIP功能的页面，当VoIP呼叫结束后，我们会执行一段JS代码，这段代码会执行一个网络请求，根据这个请求的结果进行业务上的处理，不管它的结果是成功还是失败，这个页面上的其他交互都正常（含网络请求）。而问题是：JS执行的这个网络请求后报了AJAX Error在H5的插件里VCONSOLE 里看，它没有Header，没有Response。在这个JS的请求里，前后所有的网络请求皆正常。怪异的现象。

      分析过程：1，此页面在UIWebView上加载正常，在WKWebView上有问题。2，WKWebView 有body 丢失现象，是原生首次LoadRequest时会有的问题，和我们的现象不一样。3，执行的JS的时机是在VoIP挂断后。这些有限的信息里貌似没有可用的的信息供我们去分析和参考，这是我们在脑海中有一个大胆的构想是不是网络阻断了导致的呢？我们分别用我们内部的办公软件和微信进行了测试，当我们在VoIP呼叫的时候，这两款应用都报了对方忙碌这个提示，这个提示是不是暗示我们的VoIP挂断的瞬间是不是网络不通呢？我们进行了断网测试，发现断网后的确实网络请求不带Header ，Response 也没有数据。是不是就是这个原因呢？我们SDK进行网络测试，发现网络上通的，此时我们又进入了盲区。在多个中心合作分析的情况下提示是不是线程阻塞问题，根据这个提示下分析。我们发现一个共性，就是在VoIP 页面退出后在WK的VC页面直接报了AJAX Error。当直接执行这段JS时是没有报错的。再测试不管是push 还是present VC 只要先执行WKWebView的JS 方法，再pop 或者diss VC 都有这的错。由此我们得出结论一个结论：应该先执行pop 或者diss掉VoIP页面后，再执行WKWebView的JS方法就没有问题了。再进行深度分析：WKWebView 应该做了一定的深度优化，当前如果是H5页面且在非激活状态下，它的底层是禁止网络访问的。尽量的少占系统资源。

      经过这段分析后留下两个问题：1 UIWebView为什么就可以正常执行那段JS代码呢？个人猜想，那应该是延时执行JS代码导致的。 本人亲测在VoIP挂断后，延迟执行那段JS也是可以的。