单元测试中不能忽略死代码行，而应识别、移除并验证覆盖率自然上升；死代码指永不执行的代码，需通过构建分析、引用搜索和副作用检查确认后清理。
单元测试中无法“忽略死代码行”来提升覆盖率——死代码本身就不该存在，更不该被测试覆盖。所谓“忽略”，其实是误用概念；真正要做的是：识别它、移除它、再验证覆盖率自然上升。
为什么不能也不该“忽略”死代码行
死代码指永远不会执行的代码，比如 if (false) { ... }、未调用的私有方法、或被 Tree Shaking 排除后残留的导出。Jest 覆盖率报告中的红色标记若指向这类代码，说明它本就不该在运行时存在。强行用注释绕过（如 // eslint-disable-line）对覆盖率无影响，且掩盖了真正的质量问题。
正确做法：先清理，再测准
-
用构建工具确认是否真为死代码：运行
vite build --mode production或webpack --mode=production，检查打包产物是否已剔除该代码。若已消失，说明是 Tree Shaking 正常工作，无需测试它 -
用 Terser 或 Webpack 的
stats查看 DCE（死代码消除）日志：开启optimization.concatenateModules: true和minimize: true，观察控制台是否提示类似dropping unused function subtract - 手动搜索调用链：在 VS Code 中右键点击疑似死函数 → “Find All References”。若无任何引用，且非导出给外部使用，应直接删除
-
检查 package.json 的
"sideEffects"：若设为false却仍有未删代码，说明该模块顶层存在副作用（如console.log、localStorage.setItem），需显式声明或重构
哪些情况看似“死”实则要测
别把“暂未触发的分支”当成死代码。以下必须保留并覆盖：
- 权限校验中
if (role === 'admin') { ... } else { throw new Error('forbidden') }——else分支虽不常走，但属于关键错误路径，需用 Jest 的expect(() => fn()).toThrow()覆盖 - 组件中
get derivedValue() { return this.items?.length ?? 0; }—— 当this.items = null时 getter 必须执行，需单独构造状态测试 - 异步逻辑里的
catch块：哪怕 API 稳定，也要用jest.mock('axios', () => ({ get: jest.fn().mockRejectedValue(new Error()) }))强制进入
覆盖率报告里怎么快速定位真死代码
运行 npx jest --coverage 后打开 HTML 报告，重点关注：
-
某行显示“1/2 branches covered”，但两个分支条件明显互斥且恒假（如
if (process.env.NODE_ENV === 'development') {...} else {...}在 test 环境下永远走 else）→ 这不是死代码，是环境分支，应通过jest.unstable_mockModule或配置testEnvironmentOptions模拟不同环境 -
整块代码灰底无高亮，且不在任何
if/for/try内部 → 很可能是被摇掉的导出或未引用的顶层语句，查import链和构建产物确认 -
某函数名右侧标“0/1 statements”且无调用痕迹 → 它没被任何测试导入或执行，不是覆盖率问题，是设计问题：要么删，要么补
import并写用例
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
