【WKWebview】WKWebView Cookie 同步

个人实测：js注入的方式更靠谱一点

⌈iOS⌋WKWebView Cookie 同步的一种方式

屈服于 Apple 的“淫威”，开发者不得不将 App 的网页容器从 UIWebView 迁移到 WKWebView。我们在享受后者带来的性能和功能提升的同时，也被诸如 Cookie 同步、截图、白屏等问题弄得抓耳挠腮、狼狈不堪。无疑，上述问题会随着系统更新被逐渐修复，而开发者在产品系统适配的硬性要求下只得各凭本身缝缝补补，以期望减少在用户侧出现的问题。如题，下文我们对 Cookie 同步的情况进行一些说明，并总结出一种可行的方案。

问题回顾

简言之，WKWebView 的网络模块进程独立于 App 进程，App 进程通过 HTTPCookieStorage 管理的 Cookie 系统会自动使用 IPC 通信同步到 WKWebView。同 App 侧的 HTTPCookieStorage，WKWebView 的存储结构在代码层面表现为 WKWebsiteDataStore(iOS 9+) 和 WKHTTPCookieStore(iOS 11+)，前者拥有后者。上述过程咋一看并不会有什么问题，但正因为是 IPC 来完成进程通信，它必然是异步执行的，即感官上的同步延迟。如果在这之前就进行需要验证 Cookie 的 WebView 请求，就是发现因缺少 Cookie 导致的鉴权失败。

一个典型的 🌰 是：用户通过通知等方式启动 App 打开一个和用户态关联的 Web URL，在用户登录完成之后（登录接口会进行 Set-Cookie 操作，写入用户的 auth_token 等数据）立即打开网页。此时会发现网页要求用户重新登录，如果通过 Charles 抓包