浅拷贝适用于轻量扁平只读状态，如角色基础属性；深拷贝是存档回滚刚需，应对深度嵌套结构；应分层拷贝、显式标记可存档字段，用structuredClone确保数据彻底独立。
在游戏开发中，状态保存（如存档、暂停恢复、技能预演、撤销操作）高度依赖数据隔离——改了新状态，不能意外影响原始游戏世界。这时，浅拷贝和深拷贝就不是语法技巧，而是状态安全的底层防线。
什么时候用浅拷贝：轻量、扁平、只读的状态快照
适用于结构简单、不含嵌套对象的游戏数据，比如角色基础属性（血量、等级、金币数）或 UI 面板开关状态。
- 用 Object.assign({}, state) 或 {...state} 快速生成副本，性能开销小
- 适合“只读预览”场景：例如技能释放前显示伤害预估，此时只需复制一级数值，不涉及装备、Buff、技能树等深层结构
- 注意：若 state 中有
position: {x: 10, y: 20}这类嵌套对象，浅拷贝后修改copy.position.x仍会污染原 state —— 这类字段必须单独处理或升级为深拷贝
为什么深拷贝是存档/回滚的刚需
游戏世界状态通常是深度嵌套的：玩家 → 背包 → 物品数组 → 每个物品含特效、冷却、附魔对象；NPC → AI 状态机 → 历史路径点数组 → 每个点含坐标、时间戳、事件标记。任何一层共享引用都可能导致“读档后敌人位置错乱”或“背包物品消失”。
- JSON.parse(JSON.stringify()) 最快上手，但会丢弃函数、undefined、Symbol、Date、RegExp 和循环引用（如玩家引用所在地图，地图又引用该玩家）
- 生产环境推荐 structuredClone()（现代浏览器支持），能安全处理 Map、Set、Date、RegExp、ArrayBuffer 及循环引用，且无需额外依赖
- 需兼容老环境时，用 lodash.cloneDeep 或手写带 WeakMap 循环检测的递归拷贝，确保存档数据彻底独立
实战避坑：状态保存中的典型陷阱
很多游戏卡在“看似保存成功，加载后行为异常”，问题常出在拷贝粒度失控。
- 把整个
gameWorld对象深拷贝，但其中混入了 CanvasRenderingContext2D、AudioContext 等不可序列化对象 → 报错或静默失败 - 对玩家技能冷却数组用了
slice()（浅拷贝），结果多个技能共用同一个 Timer 对象 → 一个技能重置，其他技能冷却也清零 - 用扩展运算符解构对象时未意识到其仅一层有效：
const saved = {...player, inventory: [...player.inventory]}—— inventory 里每个物品若含嵌套配置，仍需逐层深拷贝
建议策略：分层拷贝 + 显式标记可存档字段
不追求“全量深拷贝”，而是定义清晰的存档契约：
- 设计
toSaveData()方法，只提取真正需要持久化的纯数据字段（剔除函数、DOM 引用、实时计算缓存） - 对提取出的数据结构，统一用
structuredClone深拷贝，避免遗漏嵌套 - 加载时用新数据重建状态，而非尝试合并到旧对象 —— 彻底切断引用链比修补更可靠
