解构默认值仅在被解构值为undefined时生效，null/0/''等falsy值不触发，默认逻辑形成隐式分支；需分别测试undefined、null、空对象等输入以覆盖所有路径。
解构赋值默认值本身不产生分支，但它的实际生效逻辑依赖于“被解构值是否为 undefined”，而这个判断在运行时会触发隐式条件路径——这正是影响分支覆盖率（Branch Coverage）的关键点。
默认值只对 undefined 生效，null/0/'' 都不走默认逻辑
这是最容易被忽略的覆盖盲区。例如：
function getConfig({ timeout = 5000, retries = 3 } = {}) {
return { timeout, retries };
}
要真正覆盖所有分支，必须分别测试以下调用：
-
getConfig()→ 外层= {}和内层默认值全部触发（timeout=5000,retries=3） -
getConfig({ timeout: 8000 })→ 只触发retries默认值 -
getConfig({ timeout: undefined })→timeout走默认值（因为undefined），retries也走默认值 -
getConfig({ timeout: null })→timeout得到null（不走默认），retries走默认 -
getConfig({ timeout: 0, retries: false })→ 两者都不走默认，保留原始值
嵌套解构需逐层覆盖“空缺”位置
比如处理 API 响应：const { user: { name, email = 'no@domain.com' } = {} } = data;
这里的分支不止一层：
-
data为undefined或null→ 触发外层= {} -
data.user为undefined→ 触发中间= {} -
data.user.email为undefined→ 触发email = 'no@domain.com' -
data.user.email为null或''→ 不触发默认，email保持原值
用空值合并（??）或显式判断补全逻辑缺口
默认值机制无法捕获 null、'' 等“falsy 但非 undefined”的值，若业务要求统一兜底，需主动扩展：
- 用
??替代=：const { email = 'no@domain.com' } = user ?? {};→ 先防null/undefined，再进解构 - 在解构右侧做二次处理：
const { email: rawEmail = '' } = user; const email = rawEmail || 'no@domain.com'; - 单元测试中明确构造
null、0、false、''四种典型 falsy 输入，验证行为是否符合预期
工具层面的真实覆盖率提示
像 Istanbul / c8 这类覆盖率工具，通常不会把 a = b || 'default' 或 { x = 1 } = obj 单独标记为“可分支语句”，但它们会统计 obj 是否为 undefined 的执行路径。所以：
- 确保测试用例覆盖
undefined、null、{}、{ email: undefined }、{ email: null }等多种输入形态 - 避免写
const { a, b } = obj || {};—— 这会让obj为null时跳过整个解构，反而掩盖真实分支 - 优先使用
obj ?? {}，它在 AST 层更清晰，多数现代覆盖率工具能识别其条件分支
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
