必须加密且不能仅靠混淆，因Base64是编码、混淆无完整性校验；推荐Web Crypto API + PBKDF2，密钥须动态派生、IV每次随机，存档封装为{salt, iv, ciphertext, tag}；melonjs需重写me.save.set/get，密码来源可控，加密失败应降级恢复而非崩溃。
localStorage 里存的存档，不加密就等于贴在浏览器控制台里任人修改——对单机休闲游戏，简单混淆可能够用；但只要涉及排行榜、成就解锁、付费道具或防作弊逻辑，**必须加密，且不能只靠混淆**。
为什么 Base64 或变量重命名根本不算加密
Base64 是编码，不是加密；JS 混淆（如 javascript-obfuscator）只是让代码难读，但所有逻辑、密钥、算法仍在内存中明文存在。玩家用 DevTools 下断点、hook atob 或直接 patch decrypt 函数，5 分钟就能绕过。真正被篡改的不是“能不能看懂”，而是“改了之后还能不能正常加载”——而混淆完全不提供完整性校验。
Web Crypto API + PBKDF2 是当前最务实的方案
现代浏览器原生支持，无需引入第三方库，且能同时保证机密性与完整性（AES-GCM）。关键不是“用不用加密”，而是怎么管密钥：
- 绝不硬编码密钥字符串，比如
const KEY = "my-secret-123"—— 这等于没加 - 用用户输入的密码 + 随机
salt（每次存档生成新 salt）调用crypto.subtle.importKey+deriveKey派生密钥 - 每次加密必须用新 IV（
new Uint8Array(12)），且和密文一起存进localStorage，解密时原样取出 - 存档数据建议封装为 json：
{salt, iv, ciphertext, tag}，避免字段错位导致解密失败
melonJS 存档模块怎么安全接入加密
melonJS 的 me.save 默认直写 localStorage，不加密。要在不改框架源码的前提下加固，推荐在 me.save.add() 后、me.save.set() 前插入加解密层：
- 重写
me.save.set：对传入值先encryptData(value, password)，再调用原生 set - 重写
me.save.get：取出后先decryptData(stored, password)，再返回结果 - 密码来源要可控——可设为登录态 Token 派生，或首次进入时弹窗要求输入“存档口令”（不保存，仅内存缓存一轮）
- 注意：
me.save.remove()仍会删明文 key，所以加密后 key 名建议统一（如固定用"game_save_enc"）
加密失败时别崩溃，但也不要暴露原因
玩家输错密码、换设备、升级浏览器后解密失败很常见。此时：
立即学习“前端免费学习笔记（深入）”；
- 不要抛
DOMException: The operation failed这类带技术细节的错误 - 不要自动清空存档——应提示“检测到存档异常，是否从默认配置重新开始？”
- 更稳妥的做法是保留一份未加密的轻量备份（如仅存关卡号、最高分），用于降级恢复
- 所有加密操作必须包裹在
try/catch中，并确保失败后仍返回合法的默认游戏状态对象
真正难的从来不是“怎么加”，而是“密钥从哪来、在哪活、什么时候死”。前端没有绝对安全，只有攻击成本的高低。把密钥绑在用户动作上（比如输入、生物认证）、把解密逻辑藏在 Service Worker 里、甚至关键校验挪到服务端——这些不是锦上添花，而是当你的游戏开始有人批量刷榜时，你唯一能守住的防线。