Web Workers 无法访问 localStorage，因其运行在独立线程且规范限定该 API 仅限浏览上下文；替代方案包括消息代理、预加载数据或使用 IndexedDB。
localStorage 无法在 Web Workers 中直接使用，这是由规范强制规定的硬性限制，不是兼容性或实现差异问题。
为什么 Web Workers 不能访问 localStorage
Web Workers 运行在独立的线程中，与主线程完全隔离。而 localStorage 是同步、阻塞式 API，且设计上只暴露给 window 环境（即 Document 关联的全局对象）。Worker 全局作用域（WorkerGlobalScope）不包含 localStorage、sessionStorage、document 或 window 对象。
- 规范明确禁止：HTML 标准规定 Web Storage API 只能在“浏览上下文”（如页面标签页）中使用，Worker 不属于该上下文
- 主线程绑定：localStorage 的读写会触发 storage 事件，该事件仅派发给同源的其他窗口/标签页，Worker 没有 event loop 机制来监听或广播这类事件
- 线程安全风险：若允许 Worker 直接操作 localStorage，可能引发主线程与 Worker 并发读写冲突，而 localStorage 本身无锁机制
替代方案：如何让 Worker 与 localStorage 协同工作
虽然 Worker 不能直接调用 setItem 或 getItem，但可通过主线程代理完成数据交换：
- 消息传递 + 主线程中转：Worker 发送请求（如 { type: 'get', key: 'token' }），主线程收到后执行 getItem 并 postMessage 返回结果
- 预加载关键数据：页面初始化时，将必要配置或缓存数据通过 worker.postMessage() 一次性传入 Worker，避免运行时频繁跨线程通信
- 使用 IndexedDB（推荐）：IndexedDB 支持在 Worker 中直接调用，是异步、线程安全的持久化存储方案，适合 Worker 场景下的结构化数据读写
注意 sessionStorage 和 cookie 的情况
sessionStorage 同样不可在 Worker 中访问，原因与 localStorage 一致——它也属于 browsing context 特有 API。
- cookie 虽然可通过 document.cookie 读取，但在 Worker 中也无法获取；不过服务端可通过 HTTP 请求头携带 cookie，Worker 发起 fetch 时默认携带（需 credentials: 'include'）
- 所有基于 DOM 的存储机制（包括 history、location）均不在 Worker 全局作用域中
实际开发中的常见误判
有些开发者尝试在 Worker 中 require 或 import 封装了 localStorage 的工具库，但这只是语法上“看起来能跑”，实际运行会报 ReferenceError: localStorage is not defined。
- 不要依赖 polyfill 或模拟实现——无法真正绕过规范限制
- 调试时可在 Worker 中 console.log(self) 查看可用全局属性，确认不包含 localStorage
- 若需离线缓存能力，优先考虑 Cache API（Service Worker 支持）或 IndexedDB，而非强行适配 localStorage
