扩展运算符（{...obj}）仅支持浅拷贝，适合顶层属性整体替换而不破坏嵌套结构；若需局部更新深层字段，须手动解构展开，但会随层级加深而冗长易错。
扩展运算符（{...obj}）本身只能做浅拷贝，它无法自动深入嵌套对象去覆盖子属性。但如果你的目标是“只覆盖第一层默认属性”，同时保留深层嵌套结构的完整性（即不破坏原有嵌套对象），那它恰恰就是最优雅、最轻量的工具——前提是理解它的行为边界。
✅ 明确目标：只改顶层，不动嵌套
所谓“覆盖第一层默认属性”，意思是：你有一个基础配置对象，其中某些顶层键（如 timeout、retry、headers）需要被用户传入的新值替换，而这些键对应的值可能是普通值，也可能是嵌套对象或数组。你不想递归合并，只想用新值整个替换旧值——这正是扩展运算符的天然能力。
-
它会完整替换顶层属性：如果
defaults.headers是一个对象，而你传入{ headers: { 'X-Trace': 'abc' } }，那么整个headers就会被替换成新对象，原嵌套结构不参与合并 -
它不触碰未声明的嵌套字段：比如
defaults.api.baseURL没被显式覆盖，就完全保留原样，不会因为api被部分重写而丢失baseURL - 适合场景：API 配置、组件 props 默认值、主题色一级变量等，只要设计上约定“顶层键为可整体替换单元”，就非常干净
⚠️ 常见误区：误以为能“局部更新”嵌套字段
很多人试图这样写：
const config = { ...defaults, api: { ...defaults.api, timeout: 5000 } };
这看起来像在“深度覆盖”，其实只是手动展开了两层——它不是扩展运算符的能力，而是你主动解构+重组。这种写法没问题，但已不属于“单靠扩展运算符优雅覆盖”的范畴。关键点在于：
- 扩展运算符本身不做任何嵌套判断或递归操作
- 你写的
{ ...defaults.api, timeout: 5000 }是对defaults.api这个对象单独做了一次浅拷贝+覆盖，和外层的{...defaults}是两件事 - 一旦嵌套层级变深（比如
api.auth.token.refresh），手动展开就会迅速变得冗长且易错
? 推荐组合：扩展运算符 + 解构默认值
当用户传入的覆盖项可能为空或不全时，可以用解构默认值配合扩展运算符，让逻辑更健壮：
function createConfig(userConfig = {}) {
const { timeout = 3000, retry = 3, headers = {}, api = {} } = userConfig;
return {
...defaults,
timeout,
retry,
headers: { ...defaults.headers, ...headers },
api: { ...defaults.api, ...api }
};
}
这里每一层都控制在“一层浅合并”范围内：
-
headers: { ...defaults.headers, ...headers }—— 只合并 headers 这一层，不影响 defaults.headers 内部其他嵌套 -
api: { ...defaults.api, ...api }—— 同理，只替换 api 对象自身属性，不深入其子字段 - 所有操作仍基于扩展运算符，无额外依赖，语义清晰
? 小结：优雅的前提是清晰的分层契约
扩展运算符不是万能的，但它在“按顶层键原子化替换”这个模式下极为精准。真正优雅的关键，不在于强行让它做深度操作，而在于把配置结构设计成扁平化、可独立替换的单元。比如把 api.timeout 提升为 apiTimeout，或把 theme.colors.primary 拆成 primaryColor 和 secondaryColor —— 这样，扩展运算符就能用得干脆利落，不拖泥带水。
