选浅拷贝还是深拷贝需按需匹配：若对象仅读取、解构或传参且不修改嵌套属性，用浅拷贝（如{...obj}、arr.slice()）最轻量；一旦需修改嵌套属性（如copy.profile.address.city='上海'），必须深拷贝；纯一层结构可用浅拷贝，多层嵌套或含Date、RegExp等特殊类型则需深拷贝；小对象低频操作推荐structuredClone，大数组高频场景应避免无脑深拷贝，可局部深拷贝或用不可变更新模式；生产环境优先用structuredClone或lodash.cloneDeep。
选浅拷贝还是深拷贝，关键看数据结构是否会被修改、嵌套层级是否简单、以及性能是否敏感——不是越深越安全，也不是越浅越快，而是按需匹配。
先判断：这个对象会不会被后续代码改？
如果只是临时读取、解构、传参，且确定不会修改任何嵌套属性（比如只取 user.name 或 list.length），用浅拷贝完全够用，也最轻量。
- Object.assign({}, obj)
- {...obj}
- arr.slice() 或 [...arr]
一旦出现类似 copy.profile.address.city = '上海' 这种对嵌套对象的赋值，就必须上深拷贝，否则原数据会同步变。
再看结构：有没有多层嵌套或特殊类型？
纯一层对象（如 {id: 1, name: '张三', status: 'active'}）用浅拷贝没问题；但含 {user: {profile: {avatar: {...}}}} 就得深拷贝。
还要留意值里有没有 Date、RegExp、Map/Set、function 或 undefined ——这些 JSON 方案（JSON.parse(JSON.stringify())）会丢数据或报错，得换方案。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
最后权衡：性能瓶颈在哪？
小对象（几十个字段以内）、低频操作（如表单提交前备份），用 structuredClone（现代浏览器支持）最省心，它能处理循环引用和大多数内置类型。
大数组（上千项）、高频渲染（如虚拟滚动中每帧生成副本），避免无脑深拷贝。可考虑：
- 只深拷贝真正要改的子路径（用 immer 或手动 patch）
- 用不可变更新模式（如 lodash.set 配合浅拷贝）
- 业务层约束：约定只改顶层字段，嵌套字段设为只读
手写递归深拷贝适合学习和可控场景，但生产环境建议优先用 structuredClone 或 lodash.cloneDeep，它们已处理好循环引用、类型还原等边界问题。
