草稿压缩存储

要解决的具体问题

• 客户端草稿对象体积大时，直接存入 localStorage 易触发配额超限（QuotaExceeded），导致草稿保存失败。
• 长文本跟进笔记、大型草稿 JSON 会占用更多本地存储空间，增加读写耗时与清理成本。
• 仅需本地轻量存储时，引入 IndexedDB 会增加复杂度，难以快速落地。

技能如何工作

核心能力基于 lz-string 对客户端草稿 JSON 进行压缩存储，推荐使用 compressToUTF16 与 decompressFromUTF16 组合，适配 localStorage 的存储场景。

关键步骤

• 读写封装：将草稿读写逻辑成对封装，先通过 JSON.stringify 序列化草稿对象，再用 compressToUTF16 压缩为字符串，存入 localStorage；读取时先解压，再通过 JSON.parse 还原对象。
• 版本管理：存储 Key 需带版本前缀（如 crm:draft:v1:），便于后续字段调整或逻辑迭代时平滑迁移数据。
• 异常处理：解压失败时返回中文错误原因，支持手动清空损坏的草稿数据，避免异常中断后续操作。
• 衔接草稿更新：可与 Immer 的草稿更新逻辑结合，在 produce 完成草稿变更后，自动调用 saveDraftCompressed 压缩存储。

自测要点

• 验证大文本草稿的存取往返一致性，确保压缩后数据无丢失。
• 对比压缩前后字符串长度，直观验证存储空间节省效果。

适用边界与注意点

• 非加密用途：压缩仅用于节省存储空间，不等同于加密，敏感数据需额外加密方案，不可直接依赖该方式存储。
• 轻量场景优先：适用于仅需本地草稿、无需复杂查询或跨设备同步的场景，若需多端同步或高频读写，建议改用 IndexedDB 或后端存储。
• 依赖管理：需提前引入 lz-string 依赖，确保压缩与解压方法的一致性，避免因版本差异导致数据无法还原。