17370845950

WKWebView 缓存需调用 WKWebsiteDataStore.removeData(ofTypes:) 显式清理，不能依赖 NSURLCache；必须指定缓存类型（如 DiskCache、MemoryCache、ServiceWorkerRegistrations 等）、时间范围，并在 completion handler 中 reload 页面，否则仍加载旧资源。

WKWebView 的缓存不会随 NSURLCache 清除而消失

很多人调用 NSURLCache.shared.removeAllCachedResponses() 后发现 HTML5 页面依然走缓存，是因为 WKWebView 默认绕过 NSURLCache，它用的是独立的磁盘/内存缓存（WKWebsiteDataStore）。这个缓存不响应系统级缓存清理 API，必须显式调用对应接口。

清理 WKWebView 缓存的正确方式是 removeDataOfTypes

需要指定缓存类型、时间范围，并确保在主线程外异步执行（否则可能卡住 UI 或失败）。常用缓存类型包括：

• WKWebsiteDataTypeDiskCache（磁盘缓存，HTML/CSS/JS 多数落在此处）
• WKWebsiteDataTypeMemoryCache（内存缓存，短期有效）
• WKWebsiteDataTypeOfflineWebApplicationCache（AppCache，已废弃但旧页可能残留）
• WKWebsiteDataTypeServiceWorkerRegistrations（Service Worker 缓存，现代 PWA 依赖此项）

示例代码片段（Swift）：

let websiteDataTypes = [
    WKWebsiteDataTypeDiskCache,
    WKWebsiteDataTypeMemoryCache,
    WKWebsiteDataTypeOfflineWebApplicationCache,
    WKWebsiteDataTypeServiceWorkerRegistrations
]
let dateFrom = Date.distantPast
let dateTo = Date.distantFuture

WKWebsiteDataStore.default().removeData(
    ofTypes: websiteDataTypes,
    modifiedSince: dateFrom,
    completionHandler: {
        print("WKWebView 缓存已清")
    }
)

强制刷新页面前要等 removeData 完成回调

如果清理后立即 reload 页面，大概率仍加载旧资源——因为缓存删除是异步操作，且 WKWebView 内部可能还持有未释放的资源引用。务必在 completion handler 中触发 reload 或重新 loadRequest。

• 不要在调用 removeData 后立刻 webView.reload()
• 避免用 DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) 模拟等待，不可靠
• 若需用户感知“已清缓存”，建议加 loading 状态，等回调再跳转或刷新

iOS 14+ 需额外处理 HTTPCookieStore 和 localStorage

部分 H5 页面依赖 cookie 或 localStorage 维持登录态或配置，它们不属于 WKWebsiteDataStore 默认清理范围：

• WKWebsiteDataTypeCookies 必须显式加入 removeDataOfTypes 列表才能清除 cookie
• localStorage 属于 IndexedDB/WebSQL/LocalStorage 体系，对应类型是 WKWebsiteDataTypeLocalStorage
• iOS 15 起，WKWebsiteDataTypeFetchCache 也需留意（用于 fetch()/XMLHttpRequest 缓存）

遗漏这些类型，会导致“页面刷新了但登录态还在”或“配置没变”的假象。

真正难的不是写几行清理代码，而是确认哪些数据类型实际被你的 H5 页面用到，以及是否所有缓存路径都被覆盖。尤其当页面混用 AppCache、Service Worker、CDN ETag、localStorage 多种机制时，漏掉一种就等于没清干净。