WKWebView 加载 file:// 本地 HTML 时 localStorage 默认禁用，需改用本地 HTTP 服务（如 GCDWebServer）托管 HTML 并访问 http://localhost:8080，方可启用 localStorage 等 Web 存储 API。
WebView 加载本地 HTML 时 localStorage 不生效
iOS 的 WKWebView 在加载 file:// 协议的本地 HTML 文件时，默认禁用 localStorage、sessionStorage 和 Web SQL，这是 Safari 安全策略的延伸——不是 bug，是强制限制。
常见现象：页面 JS 调用 localStorage.setItem('a', '1') 无报错但查不到数据，localStorage.length 始终为 0；控制台也看不到 Storage 面板内容。
- 仅影响
file://路径，HTTP/HTTPS 服务（如http://localhost:8080）不受限 -
WKWebView默认不启用WebKitStorageAccessAPI，且该 API 对file://无效 -
UIWebView（已弃用）虽曾支持，但在 iOS 9+ 后也逐步收紧，不建议回退
启用 file:// 下 localStorage 的唯一可行方案：启动本地 HTTP 服务
绕过协议限制的实质方法，是让 HTML 不走 file://，而走 http://。iOS 并不限制本地 HTTP 响应中的存储能力。
推荐使用轻量级内嵌服务，例如 Swift 封装的 GCDWebServer：
立即学习“前端免费学习笔记（深入）”；
let server = GCDWebServer()
server.addGETHandler(forPath: "/", handler: { _ in
let htmlPath = Bundle.main.path(forResource: "index", ofType: "html")!
return GCDWebServerDataResponse(htmlFile: htmlPath)
})
try? server.start(withPort: 8080, bonjourName: nil)
然后 WebView 加载 http://localhost:8080/，此时 localStorage 完全可用。
- 无需越狱、无需 App Store 审核特殊声明（纯内网服务）
- 端口选 8080/8081 等非特权端口，避免权限问题
- 注意：不要用
0.0.0.0或外网 IP 绑定，只用127.0.0.1或默认绑定，确保仅本机可访问
替代方案对比：IndexedDB 与 cookie 是否可行？
在 file:// 下，所有基于同源策略的持久化机制都受限，不只是 localStorage：
-
IndexedDB：同样被禁用，打开数据库时会静默失败或抛SecurityError -
cookie：file://无 host，无法设置 domain/path，document.cookie读写均无效 - 原生桥接（如
WKScriptMessageHandler）+ UserDefaults：可行，但需额外封装 key/value 同步逻辑，不适合直接替换 Web 存储语义
若必须坚持 file://（如旧架构强约束），只能放弃 Web 存储 API，改用 JS 与原生双向通信 + UserDefaults 或 FileManager 持久化。
iOS 16+ 的新变化：doesNotOpenURLInWebView 与资源加载路径陷阱
iOS 16 引入了 WKWebViewConfiguration 的 doesNotOpenURLInWebView，但它不影响存储，只控制 URL 导航行为；真正容易被忽略的是资源路径处理：
- 即使启用了本地 HTTP 服务，若 HTML 中 CSS/JS 引用仍用
file://相对路径（如<script src="js/app.js">），而服务器未正确映射静态资源目录，会导致脚本加载失败，进而让存储逻辑根本没执行 - 务必确认所有
<link>、<script>、fetch()请求都落在同一 HTTP origin 下（如全为http://localhost:8080/） - 检查 Network 面板中是否有 404 或跨 origin 警告——这是“存储看似失效”最常被误判的根源
本地存储本身没有魔法，它只是同源策略下的一个副产品；iOS 的限制从来不在“存”，而在“认这个源”。把源从 file:// 换成 http://localhost，就解开了整个链条。
