概述
WKWebView Cookie Issue主要包括：
Cookie丢失问题
Cookie同步延迟问题
Cookie丢失问题
使用过WKWebView的都会遇到请求没有带上登录态，页面访问失败的情况。在UIWebView中发起的请求会自动带上存储于NSHTTPCookieStorage容器中的Cookie，因此，我们一般都会将登录态存储于NSHTTPCookieStorage中；而WKWebView发起的请求不会自动带上存储于NSHTTPCookieStorage容器中的Cookie，目前主流的解决方案是：
- loadRequest前，在request header中设置Cookie, 解决首个请求Cookie带不上的问题；
WKWebView *webView = [WKWebView new];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://y.qq.com"]];
[request setValue:@"skey=MgYzJipDFA" forHTTPHeaderField:@"Cookie"];
[webView loadRequest:request];
- 通过document.cookie设置Cookie解决后续页面Ajax、iframe等请求的Cookie问题；
WKUserContentController *userContentController = [WKUserContentController new];
WKUserScript *cookieScript = [[WKUserScript alloc] initWithSource: @"document.cookie = 'skey=MgYzJipDFA';" injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:NO];
[userContentController addUserScript:cookieScript];
这种方案在遇到302请求的时候有点捉襟见衬，比如：
第一个请求
RequestA: www.a.com,我们通过在request header里带上Cookie:skey=MgYzJipDFA解决该请求的Cookie问题，接着RequestA重定向到RequestB:www.b.com,这个时候RequestB就可能因为没有携带www.b.com域名的Cookie而失败。更棘手的是这里RequestB:www.b.com和RequestA:www.a.com其实是地址相同的同一个对象，也就是说RequestB会带上我们在RequestA header里设置的Cookie:skey=MgYzJipDFA，这样如果RequestA是重定向到第三方网站，就可能导致Cookie信息泄漏问题。当然，由于每一次页面跳转前都会调用回调函数：
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;
可以在该回调函数里拦截跳转请求，在request header中带上或擦除Cookie，确保Cookie字段信息和NSHTTPCookieStorage容器中的一致，并重新loadRequest。不过这种方法依然解决不了页面iframe跨域请求的Cookie问题，毕竟-[WKWebView loadRequest:]只适合加载mainFrame Request。
document.cookie不能垮域设置Cookie，因此，document.cookie添加Cookie的逻辑可以简单调整下:
通过-[WKUserScript addUserScript:]注入脚本A，A不再是执行document.cookie设置Cookie,而是在documentStart的时候，抛通知(webkit messageHandlers)给客户端，客户端收到通知后，从NSHTTPCookieStorage容器中取出window.location.href对应的Cookie，并执行document.cookie将Cookie注入。
Cookie同步问题
document.cookie或response set-Cookie设置的Cookie会先存储在WKWebView Cookie缓存(这里WKWebView Cookie缓存的说法可能不是很准确)中，然后再同步到NSHTTPCookieStorage容器中，而同步过程有1~2s左右的延迟（setCookie有1.5s左右的延迟，而document.cookie的延迟更高些，大概在2.0s左右）。通过document.cookie设置Cookie的时候，如果没有指定过期时间，则属于Session Cookie, WKWebView不会将Session Cookie同步到NSHTTPCookieStorage中，这点和UIWebView有点差异。WKWebView发起的请求会自动带上缓存中的Cookie而不会自动带上NSHTTPCookieStorage中的Cookie。
-
set-Cookie
- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler;通过该回调函数可以获取部分response header set-Cookie字段，将Cookie信息同步到NSHTTPCookieStorage中；
document.cookie
可以在javascript层hook document.cookie set method，不过目前发现只有IOS 10系统上能hook成功；另一种做法是设置定时器，检查document.cookie是否有更新，如果有则抛通知给客户端，客户端将Cookie信息同步到NSHTTPCookieStorage中；WKProcessPool
通过让所有WKWebView共享同一个WKProcessPool实例，可以实现多个WKWebView之间共享Cookie数据，尤其是Session Cookie;
相对完美的方案
前面两个问题的讨论都是建立在WKWebView不支持NSURLProtocol的基础上，如果WKWbView支持NSURLProtocol：
- WKWebView请求将从Network Process转发到App Process, 最后由Loading System用NSURLConnection发起请求；
- NSURLConnection发起的请求会自动带上NSHTTPCookieStorage中的Cookie;
- NSURLConnection响应的set-Cookie字段会自动存储到NSHTTPCookieStorage中；
综合上面3点，WKWebView Cookie Issue就只剩下document.cookie的同步问题；
笔者对webkit2没有特别深入的了解，如有表述错误欢迎指正！
