Web Worker 无法访问 localStorage 和 sessionStorage，但可使用 IndexedDB；前者因绑定 window 被规范禁止，后者需独立 open 且不能升级版本，适用于离线并行数据处理。
Web Worker 中不能访问 localStorage 和 sessionStorage，但可以使用 IndexedDB——不过有关键前提和操作边界。
Web Storage 在 Worker 中完全不可用
localStorage 和 sessionStorage 是绑定在主线程 window 对象上的 API，Worker 线程没有 window、document 或这些存储对象的引用。尝试访问会直接报 ReferenceError 或返回 undefined。这不是兼容性问题，而是规范层面的禁止。
- 浏览器明确不暴露
localStorage/sessionStorage全局变量给 Worker 上下文 - 即使通过
importScripts加载外部脚本，也无法绕过该限制 - 如需共享简单键值数据，必须由主线程读取后通过
postMessage传入 Worker
IndexedDB 在 Worker 中可用，但需满足条件
Worker 可以独立打开并操作自己的 IndexedDB 数据库，前提是数据库已存在且版本匹配。它不能参与主线程正在使用的同一数据库连接，但可并发访问同一数据库名（底层由浏览器协调）。
- Worker 必须调用
indexedDB.open()自行建立连接，不能复用主线程的IDBDatabase实例 - 数据库升级（
onupgradeneeded）只能在主线程触发；Worker 只能连接已存在的版本 - 事务生命周期完全独立：Worker 中的事务不会阻塞主线程，失败也不会影响主线程事务
- 注意 Safari 对 Worker 中 IndexedDB 的支持较晚，部分旧版本可能静默降级为只读或报错
为什么设计成这样？
这种差异源于浏览器对不同存储机制的安全模型与调度目标设定：
- Web Storage 是同步、轻量、面向 UI 状态的机制，天然与主线程生命周期耦合
- IndexedDB 是异步、持久、面向结构化数据的引擎，其事务系统本身支持多上下文隔离，Worker 使用它符合“离线计算+本地持久”场景需求
- 禁止 Worker 访问 Web Storage，是为了防止跨上下文隐式状态污染；允许 Worker 使用 IndexedDB，则是为支持真正并行的离线数据处理能力
实际开发建议
若需在 Worker 中做带持久化的计算任务，推荐以下模式：
- 主线程负责初始化数据库结构、处理用户交互和 UI 更新
- Worker 加载已有数据库，执行批量读取 → 本地计算 → 批量写入（全部封装在单个
readwrite事务中） - 避免在 Worker 中频繁新建/删除数据库，减少版本管理复杂度
- 使用
navigator.storage.estimate()提前检查配额，尤其在处理大文件或二进制数据时
