三元运算符本身不导致分支覆盖率盲区，问题在于测试工具将? : 视为单个conditionalexpression节点而不拆解真假分支；应优先改用if/else、拆分为布尔变量或配合副作用断言验证。
三元运算符本身不会导致分支覆盖率统计盲区，真正的问题在于测试工具（如 Istanbul / nyc）对内联表达式中条件判断的识别粒度不足——它通常只把 if、else、switch 等语句块视为“可覆盖分支”，而把三元运算符（? :）整体当作一个表达式节点，不拆解其真假分支进行独立计数。
为什么三元运算符容易被漏统计
多数覆盖率工具基于 AST 分析，但默认将 a ? b : c 视为单个 ConditionalExpression 节点，而非两个独立执行路径。即使你写了 10 层嵌套三元，只要语法合法，工具仍可能只报告“该行已执行”，却不校验 true 分支和 false 分支是否都被触发。
例如：
const status = user?.role === 'admin' ? 'granted' : user?.isActive ? 'pending' : 'denied';
这段代码实际包含 3 个逻辑分支（admin / active / denied），但 Istanbul 可能只标记整行为“covered”，无法体现 user?.isActive 的 false 路径是否运行过。
如何让三元分支真正被识别和覆盖
- 优先改用 if/else 显式展开：对影响核心逻辑或需高覆盖率的分支，主动降级为语句块。工具天然支持 if 分支统计，且可读性、可测性更强。
-
拆分复杂三元为独立变量：把每个条件提取成布尔变量，再组合。例如：
const isAdmin = user?.role === 'admin';<br>const isActive = user?.isActive;<br>const status = isAdmin ? 'granted' : isActive ? 'pending' : 'denied';
这样各布尔表达式会被单独计入“statement coverage”或“branch coverage”（取决于配置），便于验证每种组合。 -
配合测试断言反向验证分支执行：在单元测试中，不只断言最终值，还要通过副作用（如 mock 函数调用、console.log spy）确认某一分支确实进入。例如 mock 一个只在
false分支调用的函数，然后 assert 它被调用一次。
配置层面增强识别能力
Istanbul 支持 branches 覆盖率类型，但默认对三元支持有限。可在 .nycrc 中启用更细粒度解析：
{<br> "reporter": ["text", "html"],<br> "all": true,<br> "check-coverage": {<br> "branches": 95<br> }<br>}
同时确保使用较新版本（nyc@15+ + babel-plugin-istanbul@6+），它们对 ES2020+ 可选链、空值合并等语法中的三元嵌套有更好支持。必要时可搭配 babel-plugin-test-covered 插件，强制将三元编译为带覆盖率标记的 if 形式。
什么情况下可以保留复杂三元
当满足以下全部条件时，可接受其“统计不可见性”：
- 纯展示逻辑（如 JSX 中 className 拼接、文案映射）；
- 所有分支都由同一组输入完全控制，且该输入已在其他测试中充分覆盖（例如整个对象结构已通过 schema test 验证）；
- 团队约定该类代码不纳入 branch coverage KPI（仅要求 statement / function 覆盖达标）。
但需在 PR 注释或代码旁加 // istanbul ignore next 明确排除，避免误报低覆盖率。
