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 多种机制时，漏掉一种就等于没清干净。
