本文深入解释为何对象解构赋值中，将 {a: obj.b, b: obj.a} = source 应用于字面量对象与引用同一变量时行为不同——根本原因在于解构右侧表达式的求值时机与属性访问的执行顺序差异。
本文深入解释为何对象解构赋值中，将 `{a: obj.b, b: obj.a} = source` 应用于字面量对象与引用同一变量时行为不同——根本原因在于解构右侧表达式的求值时机与属性访问的执行顺序差异。
在 JavaScript 中，对象解构赋值（如 {a: x, b: y} = source）看似简洁，但其底层执行逻辑严格遵循先求值右操作数、再按左操作数顺序逐项赋值的规范。关键点在于：右侧表达式（source）仅被求值一次，且其结果在解构开始前就已确定并固化为一个不可变快照。这一设计是 ECMAScript 标准的明确要求，属于有意为之的语言特性，而非 bug。
我们来对比两个典型场景：
✅ 场景一：右侧为对象字面量（安全、可预测）
let obj = {};
({a: obj.b, b: obj.a} = {a: 1, b: 2});
console.log(obj); // { b: 1, a: 2 }
执行过程等价于：
const temp = {a: 1, b: 2}; // 右侧一次性求值，生成独立对象
obj.b = temp.a; // → obj.b = 1
obj.a = temp.b; // → obj.a = 2
由于 temp 是独立副本，两次赋值互不干扰，结果符合直觉。
⚠️ 场景二：右侧为变量引用（存在读写竞态）
let obj = {a: 1, b: 2};
({a: obj.b, b: obj.a} = obj);
console.log(obj); // { a: 1, b: 1 }
执行过程等价于：
const temp = obj; // 右侧求值 → 指向原对象的引用
obj.b = temp.a; // 此时 temp.a === 1 → obj.b 变为 1
obj.a = temp.b; // 注意：temp.b 是原始值 2？不！因为 temp === obj，
// 而 obj.b 已被上一步改为 1 → 所以 temp.b 现在是 1
更准确地说，temp.b 在第二步读取时，实际读取的是已被第一步修改后的 obj.b。因此：
- 第一步：obj.b = obj.a → obj.b = 1（此时 obj = {a: 1, b: 1}）
- 第二步：obj.a = obj.b → obj.a = 1（obj.b 已是 1）
这就是典型的自修改引用导致的赋值顺序依赖问题。
? 核心结论与最佳实践
- ✅ 这是标准的、有意的设计：ECMAScript 明确规定解构赋值中右侧表达式只求值一次，左侧模式按书写顺序依次执行。这保证了语义一致性与可预测性（尤其在异步/副作用场景下）。
- ❌ 不要假设“{a:x, b:y} = obj”等价于“分别读取 obj.a 和 obj.b 的‘初始快照’”——当 obj 是可变引用时，中间赋值会改变后续读取结果。
- ✅ 安全替代方案：若需基于原状态解构，显式创建快照：
const {a, b} = {...obj}; // 浅拷贝后解构 obj.b = a; obj.a = b; - ? 注意：此行为同样适用于嵌套解构、计算属性名及默认值场景，本质均由“右值单次求值 + 左值顺序执行”驱动。
理解这一机制，能帮你避开隐蔽的赋值陷阱，并写出更健壮、可维护的解构逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
