IndexedDB本身不提供加密或访问控制，安全关键在于应用层：敏感数据禁存明文，须用Web Crypto API（AES-GCM）加密后存储，密钥由用户凭证动态派生，严禁硬编码；所有操作需事务保障、索引优化与版本兼容管理。
IndexedDB 本身不提供加密或访问控制机制，它只是浏览器内一个同源、客户端、持久化的结构化数据存储接口。所谓“安全存储”，关键不在 IndexedDB 自身，而在于你如何使用它——尤其是存什么、怎么存、谁可见、何时删。
敏感数据坚决不存
不要把密码、密钥、短期有效的 token、身份证号、银行卡号等高敏感信息直接写入 IndexedDB。它和 localStorage 一样，属于同源可读范围：同一域名下的任意脚本（包括第三方库、恶意注入的 XSS 脚本）都能同步读取全部内容。
- 登录态建议只存无状态的、有时效的 refresh token（且需配合服务端校验），access token 应尽量短期 + 内存中管理
- 用户偏好、主题设置、表单草稿、离线缓存的 API 响应体（脱敏后）等低风险数据，才是 IndexedDB 的合理用途
- 若业务强依赖本地加密存储（如离线笔记含私密内容），应先用 Web Crypto API 加密后再存入，解密逻辑也必须在可信上下文中执行
用好事务与索引，避免意外暴露
看似是性能优化点，实则影响数据完整性与边界控制。错误的事务设计可能导致部分写入成功、部分失败，留下不一致的中间状态；缺失索引则容易触发全量遍历，增加内存泄漏或误读风险。
- 所有写操作必须包裹在
readwrite事务中，并监听onerror和oncomplete，失败时主动清理或回滚关联数据 - 为查询字段建索引（如
userId、createdAt），避免用游标遍历整个 objectStore 获取单条记录 - 删除数据时，优先用
delete()或带条件的openCursor()，别靠前端 JS 过滤后逐条清除——既慢又可能漏删
版本升级要谨慎，结构变更留痕迹
IndexedDB 的 onupgradeneeded 是唯一能修改 schema 的时机。一旦上线，旧版本数据不会自动迁移，粗暴覆盖或跳过升级逻辑，极易导致后续读取失败或数据错乱。
- 每次新增 objectStore 或索引，都必须提升数据库版本号，并在
onupgradeneeded中显式判断是否存在，再创建 - 字段废弃不等于数据可删——保留旧字段读取能力，新增字段做兼容处理（例如默认值、类型兜底）
- 对用户关键数据（如学习进度、草稿），升级前建议先备份到临时 store，升级成功后再合并，失败则还原
配合上层封装增强可控性
原生 IndexedDB API 冗长易错。采用成熟封装库（如 Dexie.js、Biscuit）可天然规避不少安全隐患：
- Dexie 支持 TypeScript 类型校验 + Promise 化 API，减少运行时 key 错误或未 await 导致的数据丢失
- Biscuit 提供自动过期、命名空间隔离、序列化/反序列化钩子，让缓存类数据更可控
- 无论是否封装，都应在应用层统一拦截写入逻辑，加入日志、采样、敏感字段过滤等轻量治理
