解构赋值非强制但更简洁安全，对象解构需配合默认值或可选链防崩，数组解构适用于固定位置提取而非动态索引或切片。
JavaScript 解构赋值不是“必须用”，而是当你需要从数组或对象中提取值时，它比传统写法更简洁、更可读、且天然支持默认值和跳过项——前提是理解它的行为边界，否则容易写出隐蔽的 undefined 或静默失败。
解构赋值在对象上为何比 .prop 访问更安全？
直接访问 obj.user.name 在 obj 或 user 为 null/undefined 时会抛 TypeError；而解构本身不报错，但需配合可选链或默认值才能真正防崩。
- 错误写法：
const { name } = user;—— 若user是undefined，直接报TypeError: Cannot destructure property 'name' of 'undefined' - 正确写法：
const { name = 'anon' } = user || {};或（ES2020+）const { name = 'anon' } = user?.;（注意：可选链不能直接用于解构左侧，需先做保护） - 真实场景：API 返回可能缺失字段，用默认值解构比一堆
user && user.name ? user.name : 'anon'更干净
数组解构为何不能直接替代 slice() 或 at()？
解构是按索引顺序“取固定位置”的值，不是随机访问或切片工具。它适合已知结构的提取，不适合动态索引或长度不确定的场景。
-
const [first, , third] = arr;可跳过第二项，但无法跳到“倒数第一项”——arr.at(-1)更合适 -
const [head, ...tail] = arr;看似像slice(1)，但tail是新数组，且当arr长度 tail 为空数组，不会报错 - 性能提示：解构本身无额外开销，但若频繁对大数组解构前
slice()，不如直接索引访问
let 声明与解构赋值混合时为何会报 ReferenceError？
因为解构赋值语句在声明阶段会触发“暂时性死区（TDZ）”，尤其在块级作用域中容易踩坑。
立即学习“Java免费学习笔记（深入）”；
- 错误示例：
{ console.log(x); // ReferenceError let x = 1; const [a, b] = [x, 2]; // 同样，x 还没初始化完就参与解构 } - 正确做法：确保被解构的变量已声明并初始化，或把解构放在声明之后
- 常见陷阱：函数参数解构 + 默认值中引用外部变量，如
function fn({ id = globalId }) { ... }，若globalId尚未定义，会报错而非用undefined
解构真正的复杂点不在语法，而在它和 JavaScript 的“真值判断”“空值处理”“作用域时机”交织在一起——写一行 const { a, b } = obj; 很快，但加个默认值、嵌套一层、再进个循环，就很容易漏掉某处 undefined 传播。别把它当语法糖，要当一个有明确契约的提取协议来用。
