web worker 本身不自带状态持久化能力，需结合 indexeddb、service worker、localstorage 等机制实现跨会话数据保留与恢复；应明确状态生命周期、单写入口及降级策略。
Web Worker 本身不自带状态持久化能力——它在页面关闭或 Worker 被终止后，内存中的变量、缓存、中间计算结果全部丢失。所谓“状态持久化”，实际是指在 Worker 生命周期之外，将关键数据可靠地落盘或跨会话保留，并在下次启动时恢复可用。这不是 Worker 自身的特性，而是需要结合浏览器存储机制与合理架构设计来实现。
用 IndexedDB 在 Worker 中直接持久化
IndexedDB 可在 Web Worker 线程中完整使用（无需主线程代理），适合存结构化、高频写入的状态，比如日志、缓存模型参数、任务进度快照等。优势在于异步、容量大（通常 ≥50MB）、支持索引查询。
- Worker 内直接打开数据库：
indexedDB.open(...)，无需通过主线程中转 - 每条状态变更可封装为事务写入，例如保存 AI 流式生成的已接收 token 序列和时间戳
- 配合定时清理策略（如只保留最近 1000 条记录），避免无限制增长
- 页面重启后，Worker 启动时可通过读取 DB 恢复上次未完成的任务上下文
借助 Service Worker 实现跨页面/离线状态保活
Service Worker 天然具备后台驻留能力，即使用户关闭标签页，只要注册成功且未被系统回收，就能维持模型加载状态或任务队列。WebLLM 等方案已验证其可行性。
- 将 AI 引擎实例托管在 Service Worker 中，多个页面通过
postMessage与其通信 - 引入心跳机制（如每 10 秒发送 keepAlive 消息），防止浏览器自动终止空闲 SW
- 利用 SW 的
clients.matchAll()管理活跃页面连接，实现状态广播与同步 - 配合 Cache API 或 IndexedDB，做到模型权重、会话历史、用户偏好三者统一持久化
主线程协同 + localStorage / 文件系统兜底
对轻量级状态（如用户设置、开关状态、最后操作时间），可由主线程统一管理并同步至 Worker；Worker 仅负责计算，不承担持久化责任，降低复杂度。
- 主线程监听
storage事件，当 localStorage 变更时主动通知 Worker 更新本地副本 - 在 NW.js 或 Electron 环境中，Worker 可直接调用 Node.js
fs模块，将状态序列化写入本地 JSON 文件 - localStorage 适合做快速 fallback：Worker 初始化时先尝试读取，失败则用默认值，避免阻塞启动
状态同步模型需明确生命周期边界
持久化不是目的，可靠的状态流转才是关键。必须定义清楚“什么该存”“何时存”“谁负责读”“冲突怎么解”。
- 避免 Worker 和主线程同时写同一份状态——推荐单写入口（如仅主线程 commit，Worker 只读+缓存）
- 对流式任务（如 useChat 中断场景），持久化重点应是“已接收数据 + 游标位置”，而非整个 React state
- 使用 UUID 或会话 ID 作为存储 key 前缀，隔离不同用户/会话的数据，防止交叉污染
- 写入失败时要有降级路径（如退回到内存暂存 + 页面卸载前强制 flush）
