用覆盖率工具发现未执行的冗余分支，核心是结合分支覆盖率报告定位未走过的if/else、switch case等路径，并人工判断是否真冗余：先查istanbul/nyc报告中红色未覆盖分支，再分析是测试遗漏、逻辑排除还是防御性代码，辅以ts/eslint静态检查，最后通过构造输入、调用链分析和回归测试验证清理。
用覆盖率工具发现未被执行的冗余分支，核心是结合代码覆盖率报告（尤其是分支覆盖率）定位那些“写出来了但从未走过的 if/else、switch case、三元表达式等逻辑路径”，再人工判断是否真冗余。关键不在工具本身，而在如何解读和验证。
用 Istanbul/nyc 看清分支执行情况
Istanbul（常通过 nyc 运行）是最常用的 JS 覆盖率工具，它会统计 分支覆盖率（Branch Coverage），明确标出每个条件判断中哪些分支被执行、哪些被跳过。
- 运行测试并生成 HTML 报告：
nyc --reporter=html npm test，然后打开coverage/index.html - 在报告中切换到 “Branches” 标签页，或直接查看源码文件 —— 未执行的分支会标为红色（如
if (x) { ... } else { ... }中的else块背景变红） - 特别注意：Istanbul 对三元运算符
a ? b : c、逻辑运算符&&/||、switch 的 default 和未命中 case 都视为独立分支，都会单独计数
区分“未覆盖”和“真冗余”
分支未被执行 ≠ 一定冗余。需结合上下文判断：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
是否被测试遗漏？ 比如某个错误状态（
error === 'TIMEOUT'）没在测试里构造，分支只是暂未触发，不是多余 -
是否已被逻辑排除？ 如函数开头有
if (!data) return，后面所有分支都依赖data存在，则后续if (data.foo)的else分支可能永远进不去 —— 这才是可疑冗余 -
是否是防御性代码？ 比如
typeof x === 'string' ? x.toUpperCase() : ''，若类型系统（TS/JSDoc）已保证x必为 string，那else就是冗余
配合静态分析缩小嫌疑范围
纯靠运行时覆盖率会漏掉“根本不可能执行”的分支（比如死代码）。可辅以静态检查：
- 用 TypeScript 编译器开启
allowUnreachableCode: true并观察警告（虽然默认关闭，但配合strict模式常能暴露明显死分支） - ESLint 插件如
eslint-plugin-sonarjs提供no-redundant-optional-chain、no-duplicate-branches等规则，能识别部分模式化冗余分支 - 对常量条件做快速扫描：如
if (process.env.NODE_ENV === 'development') {...} else {...}在 prod 构建中，else 分支恒不执行，可考虑移除或用编译时剔除（如 webpack DefinePlugin）
验证与清理要动手试，不能只看报告
发现红色分支后，别急着删。安全做法是：
- 尝试手动构造输入，强制进入该分支（哪怕临时改代码），确认它是否真有逻辑作用
- 搜索调用链：这个函数被谁调用？上游是否已过滤了某种状态？
- 删掉疑似冗余分支后，重新跑全部测试 + E2E，确保没功能倒退；再补一个测试用例，显式覆盖你刚删掉的路径（用来证明它确实不需要）
- 如果是公共库或遗留系统，加注释说明删除理由（例如：
// removed: unreachable after auth refactor in PR #123）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
