防篡改需校验+加密+拦截协同实现：哈希快照校验敏感键、aes-gcm加密存储、封装setitem入口控制、performanceobserver监控异常写入，核心是确保仅可信逻辑可修改。
Web Storage 本身不防篡改，localStorage 和 sessionStorage 都是开放的、可被任意脚本读写的内存区域。所谓“防篡改”，不是靠 Storage 接口自身实现，而是靠前端主动构建的校验机制 + 加密存储 + 运行时监控三者协同完成。
哈希快照校验：识别谁改了关键数据
页面加载时，对敏感键（如 authToken、userRole）的值做一次 SHA-256 哈希，存入内存 Map，不落地；后续监听 storage 事件，仅比对当前值哈希与初始快照是否一致。不一致即判定为外部篡改。
- 只校验明确列出的键，避免遍历全部 localStorage 导致性能拖慢
- 校验逻辑必须轻量——不解析大 JSON、不发起网络请求、不触发 DOM 操作
- 发现篡改后，建议立即清除该 key 并重定向登录页，而非仅弹窗提示
加密存储前置：让篡改失去意义
即使 localStorage 被改，若存的是密文且密钥未泄露，攻击者也无法还原原始数据。推荐使用 Web Crypto API 的 AES-GCM 模式：
- 密钥长度严格为 256 位，IV 每次加密随机生成且固定 12 字节
- 加密结果转成 base64url 编码，连同 IV 一起结构化存储：
{ iv: "...", data: "...", salt?: "..." } - 密钥绝不硬编码、不存 localStorage、不从 URL 或 cookie 中读取；优先用 PBKDF2 派生（盐值单独存），或临时会话密钥（仅内存持有）
写入入口控制：从源头切断非授权修改
Storage 事件只是“事后通知”，真正有效的防线在写入发生前。应封装受控存储代理：
- 全局禁用原生
localStorage.setItem，替换为自定义方法 - 只允许白名单模块调用（如 authService、configManager），其余一律拒绝
- 对写入内容做基础类型和格式校验（如 token 必须含 “.”、theme 只能是 “light”/“dark”）
运行时行为监控：捕捉异常写入模式
恶意脚本常通过高频 setItem 实现覆盖或 DoS。可用 PerformanceObserver 主动识别：
- 监听 longtask，过滤出调用栈含
localStorage的任务 - 设定阈值：1 秒内 ≥ 5 次 setItem，或单次耗时 > 8ms，即标记为可疑
- 触发后可冻结 localStorage（重写 setItem 为空函数）、记录堆栈并上报，而非等待篡改完成
不复杂但容易忽略：防御重点不在“监听谁改了”，而在“确保只有可信逻辑能改”。storage 事件只是最后一道哨兵，真正的防线建在初始化校验、运行时拦截和行为监控上。
