浅拷贝与深拷贝的本质区别在于修改副本是否影响原对象：若obj.a.b.c=999后原obj.a.b.c也变，则为浅拷贝；仍为1才可能是深拷贝。需用两层以上嵌套实测，警惕展开运算符、Object.assign等仅断第一层引用的“假复制”。
浅拷贝和深拷贝的问题，本质不是“复制得够不够多”，而是“改拷贝体时，原对象会不会动”。只要改了副本导致原始数据意外变化，就是拷贝没做对——不是方法错了，是没看清数据结构的嵌套层级和类型边界。
一眼识别是不是真拷贝：三步验证法
别信变量名，用修改+回查的方式实测：
- 找一个至少两层嵌套的对象，比如obj = { a: { b: { c: 1 } } }
- 用你选的方法生成副本copy，然后执行copy.a.b.c = 999
- 立刻检查obj.a.b.c的值：如果是999，说明是浅拷贝或赋值；如果是1，才可能是深拷贝
这个测试比看文档更可靠。很多团队线上出问题，就是因为只在单层对象上测过，没碰过三层嵌套+数组混合的结构。
常见浅拷贝方案的“隐性共享”场景
这些写法看着像复制，其实只断开了第一层引用：
- 展开运算符：{...obj} 或 [...arr] —— 数组里放对象、对象里有 Date，照样共享
- Object.assign：Object.assign({}, obj) —— 不处理原型链，也不递归，Map/Set/RegExp 直接丢掉
- Array.from 和 slice() —— 对一维数组安全，但arr[0]是对象时，那个对象仍被共用
典型翻车现场：表单默认配置含{ filters: { price: { min: 0, max: 100 } } }，用展开复制后改copy.filters.price.max，结果所有未提交的页面都同步变了上限。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
深拷贝方案选型：别迷信“一行解决”
没有万能解法，得看你的数据长什么样：
- JSON.parse(JSON.stringify())：快、简洁，但会丢undefined、function、Symbol、Date、RegExp、NaN、Infinity、循环引用，Date 变成字符串，正则变空对象
- structuredClone()（现代浏览器 & Node.js 17+）：支持Map、Set、Date、RegExp、ArrayBuffer、TypedArray、Error，自动处理循环引用，但不支持函数和 Symbol 属性
- lodash.cloneDeep：最全兼容，函数、Symbol、自定义类都能保，但体积大，tree-shaking 效果一般
- 手写递归 + WeakMap：适合对性能和控制力要求高的场景，可精准处理循环引用、特殊类型、不可枚举属性，但开发成本高
建议：新项目优先用structuredClone；老项目兼容 IE 或需函数保留，再考虑 lodash；临时调试或纯 JSON 数据，JSON 方法够用但务必加注释提醒边界。
真实业务中高频踩坑点
这些不是理论，是线上日志里反复出现的模式：
- React useState 初始化：写const [data, setData] = useState(defaultObj)没问题，但后续setData({...data})只是浅拷贝，嵌套改了就污染 defaultObj
- Vue 响应式对象解构：const { list, config } = reactiveObj 后直接改list.push()，触发的是原响应式对象变更，不是新建一份
- 接口响应缓存复用：把 axios 返回的res.data直接存进 store，下次取出来编辑，等于在改缓存里的原始响应体
- 表格行内编辑保存前校验：用浅拷贝生成临时编辑态，但校验逻辑里调用了tempRow.children?.map(...)，children 是引用，map 返回的新数组元素仍是原对象
根本解法不是换工具，而是建立“凡是嵌套结构，先问一句：我改它，别人会不会也看到？”的习惯。
