Web Worker 无法直接访问 localStorage 或 sessionStorage，因其运行在独立线程且隔离上下文；应通过主线程代理读写、内存暂存中间状态、消息传递轻量数据或服务端协同实现无状态计算。
web worker 无法直接访问 localstorage 或 sessionstorage，这是由浏览器设计决定的——worker 运行在独立线程和隔离上下文中，不共享主线程的 dom、window 对象及 web storage api。这不是 bug，而是安全与架构约束。要解决数据存储需求，关键不是“绕过限制”，而是根据场景选择合适的数据传递与缓存策略。
用主线程代理读写，Worker 仅负责计算
Worker 本身不存状态，但可与主线程协作：所有需持久化的操作（如保存用户偏好、草稿）仍由主线程执行；Worker 负责处理耗时逻辑（如解析大文件、加密、校验），再把结果发回主线程存入 Storage。
- 主线程监听
message事件接收 Worker 的处理结果，调用localStorage.setItem()持久化 - Worker 启动前，主线程可通过
postMessage()把必要配置（如初始参数、token 片段）传入 - 避免在 Worker 中尝试访问
localStorage—— 会直接报ReferenceError或静默失败
使用内存对象 + 消息传递暂存中间状态
若只需在 Worker 生命周期内保留临时数据（如分块处理的累计值、缓存的哈希表），直接用普通 JavaScript 对象、Map 或 Set 即可。这些存在于 Worker 自身堆内存中，无需跨线程同步。
-
const cache = new Map();存储高频查表项，Worker 结束即释放 - 对敏感中间结果，可用
WeakMap关联处理对象，避免内存泄漏 - 不依赖任何持久化机制，完全规避 Storage 限制
通过 URL 参数或 postMessage 传递轻量结构化数据
当 Worker 需要“携带”少量可序列化状态（如任务 ID、时间戳、开关标记），优先走通信通道而非本地存储。
- 创建 Worker 时用
new Worker('worker.js', { type: 'module' })，配合importScripts或动态import()加载依赖，避免硬编码参数 - 主线程调用
worker.postMessage({ taskId: 'abc123', timestamp: Date.now() }) - Worker 内通过
self.onmessage解构接收，不落地、不缓存、不依赖外部 API
服务端协同：将状态上收，Worker 只做无状态计算
真正需要跨会话、跨设备一致的状态（如用户设置、任务进度），不应放在前端任何存储中，而应由后端托管。Worker 可专注完成纯计算任务，完成后由主线程发起 API 请求提交结果。
- Worker 输出结构化数据（如校验报告、压缩包元信息），主线程封装成 JSON 发送至服务端
- 服务端返回唯一 task_id 或 session_token，主线程存入
localStorage或内存，供后续查询 - 这样 Worker 始终是无状态的，也符合其“后台计算单元”的定位
