html5离线缓存无法真正加密，因前端无可信执行环境，密钥必然暴露；应避免缓存敏感数据，优先采用服务端加密+短时效密钥派生，结合身份认证与权限控制保障安全。
HTML5 本身不提供离线缓存内容的“加密”能力。所谓“HTML5 离线缓存加密”，本质是混淆概念——Application Cache（AppCache）已被废弃，且从不支持加密；Service Worker + Cache API 也不加密缓存数据。浏览器缓存（包括 localStorage、IndexedDB、Cache API 存储）均以明文形式保存在用户设备本地，无法由前端代码真正加密后安全落盘。
为什么浏览器端无法实现真正意义上的“离线缓存加密”？
根本原因在于：前端运行环境（JavaScript）不具备可信执行环境（TEE），密钥必然暴露在内存或源码中。即使你用 CryptoJS 或 Web Crypto API 对资源内容加密后再存入 Cache API，解密密钥也必须随 JS 一起下发——攻击者可轻松通过调试器提取密钥、还原原始内容。本地存储 ≠ 安全存储。
实际可行的替代方案（按优先级推荐）
- 敏感内容不离线缓存：仅缓存公开、非敏感的静态资源（如 logo、CSS、通用 JS）。登录态、用户数据、私有文档等一律禁止存入 Cache API / IndexedDB 明文
- 服务端动态加密封装：若必须离线使用加密内容，应由服务端用用户专属密钥（如基于登录凭证派生的密钥）加密资源，再下发。前端用 Web Crypto 解密（密钥仍需安全获取，建议通过短时效 Token 换取派生密钥，避免硬编码）
- 结合 HTTPS + Service Worker 强制离线兜底逻辑：用 SW 拦截请求，对已缓存资源直接返回；对未缓存或需鉴权的资源，返回友好提示（如“请联网查看该内容”），不尝试本地解密
- 利用 Credential Management API 或 WebAuthn 增强身份可信度：在解密前验证用户当前是否为合法持有者（例如要求指纹/密钥认证），提升本地解密操作的安全边界
常见误区提醒
✘ 把 base64 编码当加密 —— 完全无安全意义
✘ 在 JS 中写死 AES 密钥并用于本地加解密 —— 密钥可被一键提取
✘ 依赖 AppCache 的 manifest 文件做“加密控制” —— AppCache 已被所有主流浏览器弃用，且 manifest 本身完全透明
✘ 认为 HTTPS 缓存 = 加密缓存 —— HTTPS 只保护传输过程，落地后仍是明文
真正的离线安全，靠的是策略分级与权限收敛，不是前端“加个密”就能解决。重点放在：什么该缓存、什么绝不能缓存、谁有权触发解密、解密前如何二次确认身份。
