关卡状态必须用独立对象管理，避免全局变量污染；每个关卡应封装为类，实现生命周期钩子并显式清理资源；持久化数据需序列化、校验类型并加版本前缀；canvas与音频须主动暂停；共享数据应只读或通过服务层受控修改。
关卡状态必须用独立对象管理，别堆在全局变量里
直接把 currentLevel、playerHealth、score 全塞进 window 或一个大对象里，后期加新关卡或调试时极易互相污染。比如第3关的敌人配置意外覆盖了第2关的掉落物表，但错误只在重进第2关时才暴露。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 每个关卡用独立构造函数或类封装，如
Level1、Level2，各自持有init()、update()、destroy() - 关卡切换时，显式调用上一关的
destroy()清理定时器、事件监听、Canvas 绘图上下文引用 - 用弱引用（
WeakMap）缓存关卡实例，避免 dom 或资源卸载后内存泄漏
localStorage 存关卡数据前必须序列化结构，别直接存 Canvas 对象
常见错误是把整个关卡实例（含 canvas、Image、Audio 等非可序列化对象）传给 localStorage.setItem('save', obj)，结果静默失败或只存了个空对象。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 定义清晰的「可持久化数据契约」：只存数值型状态，如
{ level: 5, coins: 127, unlocked: [1,2,3,5] } - 用
json.stringify()+JSON.parse()双向转换，存前校验字段类型（例如typeof data.level === 'number'） - 为防跨设备/跨浏览器兼容问题，键名加版本前缀，如
gameSave_v2，升级时提供迁移逻辑
状态切换时 Canvas 和音频要主动暂停，否则后台继续消耗 CPU
用户切到第2关，但第1关的 requestAnimationFrame 还在跑，背景音乐还在 play()，不仅耗电，还可能造成音效叠加、帧率抖动。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有关卡类实现统一生命周期钩子：
onEnter()（恢复渲染/音频）、onExit()（取消raf、audio.pause()、清空setTimeout） - 用
document.hidden监听页面可见性，在visibilitychange事件中统一暂停当前关卡，避免用户切标签页后游戏仍在运行 - 音频资源用
AudioContext.suspend()控制整体状态，比单个Audio实例更可靠
跨关卡共享数据要设访问边界，别让 Level3 意外改了 Level1 的配置
比如把敌人血量表 ENEMY_STATS 放在顶层，Level3 里写了 ENEMY_STATS.goblin.hp = 1，结果回退到 Level1 时小怪秒杀——这种隐式耦合极难定位。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 共享数据只读化：用
Object.freeze()封装配置表，或用class+get访问器控制读取 - 需要动态修改的（如技能解锁），走明确的「服务层」，如
PlayerProgress.unlockSkill('fireball')，内部做校验和广播 - 调试时加断点监控：在共享对象的 setter 或 Proxy 中 throw Error，快速捕获非法写入
关卡越多，状态边界越容易模糊；最麻烦的不是存不下数据，而是某个 levelData 被三个地方同时 mutate，而你只在 console.log 里看到最终结果。