JavaScript数据缓存需按需存储、合理淘汰、安全读写：内存缓存用Map+时间戳+LRU；localStorage需序列化、加版本号、禁存敏感信息；IndexedDB和Cache API适用于大容量或离线场景；策略应匹配业务节奏，注重一致性与隔离性。
JavaScript 中实现数据缓存，核心是“按需存储 + 合理淘汰 + 安全读写”，不是简单用一个对象存起来就完事。关键在于根据场景选择缓存位置（内存、localStorage、IndexedDB）、设定有效时间、处理并发请求，并避免缓存污染和过期数据误用。
内存缓存：快但易失，适合短期高频数据
用普通对象或 Map 存储是最直接的方式，响应快、无序列化开销，但页面刷新即丢失，且不共享于 Tab 间。
- 用 Map 比对象更合适：支持任意类型 key（如函数、对象），可精确控制大小，方便遍历清理
- 加时间戳 + 过期检查：每个缓存项记录
timestamp和maxAge（毫秒），读取前判断是否过期 - 限制容量防内存泄漏：例如 LRU 策略，用 lru-cache 或手写简易版，超限时删最久未用项
持久化缓存：localStorage / sessionStorage
适合用户偏好、配置、离线可用的只读数据（如字典、静态接口返回），但注意容量限制（通常 5–10MB）和同步阻塞问题。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 必须 序列化：用
JSON.stringify()存，JSON.parse()取；遇到 Date、RegExp、undefined 会丢信息，需自定义序列化逻辑 - 加版本号字段：比如
cache_v2_user_profile，升级格式时自动清旧缓存，避免解析失败 - 不要缓存敏感信息：localStorage 不受 HTTPS 保护，且同源下所有脚本都可读，密码、token 禁止存这里
高级缓存：IndexedDB + Cache API（PWA 场景）
需要大容量、结构化、异步持久存储时选 IndexedDB；做离线资源缓存（HTML/CSS/JS/图片）则用 Service Worker 的 Cache API。
立即学习“Java免费学习笔记（深入）”；
- Cache API 更轻量：用
caches.open('api-v1')开仓，cache.match()查，cache.put()存，天然支持 Request/Response 对象 - IndexedDB 适合复杂查询：比如缓存分页列表，按时间范围检索；建议封装成 Promise 化工具（如 idb 库）简化使用
- 注意缓存一致性：服务端数据更新后，前端需主动 失效对应缓存（如删除 key、更新 version、发广播通知其他 Tab）
缓存策略设计要点
策略不是技术堆砌，而是围绕业务节奏来定：
- 读多写少 → 强缓存：如城市列表、国家编码表，maxAge 设为 24 小时以上，配合 ETag 或 last-modified 校验
- 实时性高 → 弱缓存或不缓存：如聊天消息、股价，优先用长连接推送，本地仅暂存最近 50 条滚动内存缓存
- 用户私有数据 → 带身份隔离：key 拼上 userId，避免 A 用户看到 B 的缓存结果（尤其在单页多账号切换时）
- 错误也缓存？谨慎：对 404、500 响应可短时缓存（如 30 秒），防止雪崩重试，但要标记为 error cache，避免掩盖真实问题
