IndexedDB 无内置加密，需在应用层用 Web Crypto API 实现 AES-GCM 加密，密钥应通过 PBKDF2 派生并安全存储，IV 每次随机生成且与密文共存，加密须嵌入所有数据库操作流程。
IndexedDB 本身不提供内置加密机制，所有数据默认以明文形式存储在用户设备上。若需加密，必须在应用层手动实现——即在写入前加密、读取后解密，核心在于“加密发生在 JavaScript 中，而非数据库本身”。
选择合适的前端加密算法
浏览器环境推荐使用 Web Crypto API（原生、安全、无需第三方库），避免老旧或不安全的方案（如 CryptoJS 的 ECB 模式、自研简单异或加密）。
- 对称加密首选 AES-GCM：支持认证加密，可同时保证机密性与完整性，且现代浏览器广泛支持
- 密钥不应硬编码或存在 localStorage；建议用 deriveKey + PBKDF2 基于用户密码派生，或结合生物认证（WebAuthn）增强密钥保护
- 避免直接用用户密码加密数据——必须加盐、迭代足够次数（如 100,000 轮 SHA-256）
加密流程嵌入 IndexedDB 操作链
加密不是附加功能，而是数据存取的必经环节。需将加密逻辑自然融入 open、add、get、put 等操作中。
- 写入前：获取原始数据 → 调用 encrypt()（含生成随机 IV）→ 将密文 + IV + 算法参数序列化为对象 → 存入 IndexedDB
- 读取后：从 DB 取出加密对象 → 提取密文与 IV → 调用 decrypt() → 返回明文数据
- IV 必须每次加密随机生成，且与密文一同持久化（不可复用，也不可省略）
密钥安全管理是成败关键
再强的加密算法，一旦密钥泄露，数据即等同裸奔。浏览器端无法做到绝对安全，但可显著提升攻击门槛。
立即学习“前端免费学习笔记（深入）”；
- 密钥绝不以字符串形式出现在代码或内存中过久；使用 CryptoKey 对象并标记
extractable: false - 用户退出登录时主动调用
clearKeys()（如清空内存中的 KeyHandle 或销毁临时密钥） - 敏感场景可结合 Secure Context + HTTPS 部署，防止中间人窃取密钥派生过程中的密码输入
注意 IndexedDB 自身局限与风险点
加密解决的是静态数据安全，但无法覆盖全部威胁面，需同步规避常见误用。
- 不要加密整个数据库名或 objectStore 名——它们始终明文可见，应避免含敏感语义（如 “user_payment_db”）
- 错误处理要严谨：解密失败（如密钥错、数据损坏）应静默拒绝返回，不抛出含调试信息的异常
- 备份与同步场景需额外设计：若数据需跨设备解密，密钥管理策略必须统一，避免“一地加密、异地无法解”
