LocalStorage 不能直接与 WebSocket 实时联动，但可作为本地缓存层配合其实现断网容错与在线同步：WebSocket 负责实时通信和权威状态下发，LocalStorage 仅作离线暂存、启动恢复和 UI 快速响应，前端收到消息后立即更新 UI 并同步写入 LocalStorage，页面加载时优先读取 LocalStorage 再连接 WebSocket 比对并拉取差异数据，服务端状态为唯一权威，冲突时依时间戳或服务端合并策略处理。
LocalStorage 本身不能直接与 WebSocket 实时联动，但可以作为客户端状态的本地缓存层，配合 WebSocket 实现“断网容错 + 在线同步”的混合状态管理。关键在于明确分工：WebSocket 负责实时通信和权威状态下发，LocalStorage 负责离线暂存、启动恢复和 UI 快速响应。
WebSocket 主动推送状态，LocalStorage 仅作被动缓存
不要让 LocalStorage 触发 WebSocket 发送，而应由服务端或主客户端通过 WebSocket 主动广播状态变更。前端收到消息后：
- 立即更新 UI，保证响应速度
- 同步写入 LocalStorage，例如：
localStorage.setItem('userStatus', JSON.stringify(data)) - 避免在 onmessage 中做复杂逻辑或 await 异步操作，防止阻塞接收
页面加载时优先读 LocalStorage，再发起 WebSocket 连接并比对
用户刷新或重进页面时，可先从 LocalStorage 恢复界面（如未读数、编辑草稿、主题偏好），再连接 WebSocket 获取最新全量/增量状态：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 连接成功后，发送一个
{ type: 'sync_request', client_id: 'xxx', last_sync_ts: 1712345678 }给服务端 - 服务端对比时间戳或版本号，只推送差异数据（如新消息、已被他人修改的条目）
- 前端合并后，覆盖 LocalStorage 并刷新视图
处理冲突：LocalStorage 是临时副本，服务端状态为唯一权威
当用户离线期间修改了本地数据（如保存草稿），上线后需与服务端状态协调：
立即学习“前端免费学习笔记（深入）”；
- 用带时间戳或 vector clock 的版本标识区分本地修改和服务端版本
- 简单场景可用“最后写入获胜”（LWW）：本地时间 > 服务端时间则提交，否则丢弃并拉取最新
- 重要数据（如文档协作）建议服务端做合并（如 OT 或 CRDT），前端只负责提交变更而非决定胜负
注意 LocalStorage 的局限性与替代方案
LocalStorage 是同步阻塞 API，大体积数据（>5MB）易卡顿；不支持跨域、不触发事件监听、无法监听变化。实际项目中建议：
- 小状态（用户设置、token、轻量草稿）用 LocalStorage + JSON 序列化
- 大状态或需监听的场景改用 IndexedDB，并封装成 Promise 化接口
- 搭配 storage 事件监听同源其他 tab 的变更（但 WebSocket 连接页自身不触发该事件）
