核心是收窄覆盖率统计范围以真实反映重构进展：通过配置工具限定目录、标记免测代码、用运行时数据验证废弃逻辑，并以diff覆盖率和文档记录替代全局阈值。
排除老旧遗留代码对覆盖率统计的干扰，核心不是“隐藏问题”，而是把统计范围收窄到当前重构目标上——让数字真实反映你正在改的那部分代码的质量进展。
明确划定“重构关注区”
老旧项目里常混着大量历史模块，比如已下线功能的 JS 文件、废弃的 polyfill、被替代的旧版组件。这些代码本身不该再被测试覆盖，但默认会被计入总覆盖率，拉低数值、掩盖真正薄弱的新逻辑。解决方法是主动配置覆盖率工具，只统计你关心的目录或文件模式：
- Jest：在 jest.config.js 中设置
collectCoverageFrom，只包含待重构模块路径，例如：collectCoverageFrom: ["src/features/payment/**/*.{js,ts}", "!src/features/payment/**/legacy/*.js"] - nyc / Istanbul：在 .nycrc 的
include字段中显式列出重构中的目录，同时用exclude屏蔽已标记为“冻结”的旧模块（如"src/legacy/**"） - Vitest：在 vitest.config.ts 的
coverage.include中写明新功能路径，避免通配符无差别扫描整个src/
给遗留代码打“免测标”
有些老旧代码虽未下线，但短期内不参与重构，也不应被要求补测试。这时可用注解 + 工具协同方式跳过统计：
- 在关键旧函数顶部添加
// istanbul ignore next注释，Jest + Istanbul 会跳过该函数的语句与分支计数 - 对整块废弃逻辑，用
/* istanbul ignore start */ ... /* istanbul ignore end */包裹，避免误判为未覆盖 - 配合 ESLint 规则
no-unused-vars和no-unreachable，交叉识别哪些“未覆盖”实为死代码而非测试缺失
用运行时数据验证“真废弃”
静态排除有风险——万一标为“免测”的代码其实还在生产环境被调用呢？建议结合 Chrome DevTools 的 Coverage 面板做二次确认：
- 启动录制，走一遍核心用户路径（登录→下单→支付成功）
- 查看那些被 exclude 的 JS 文件：如果整份文件都是红色（未执行），基本可确认已退出主流程
- 若某旧模块中只有个别函数标红，其余蓝了，说明它仍有残留调用，此时不应整体排除，而应定位具体调用点，针对性迁移或隔离
把覆盖率当重构进度刻度，而非达标门槛
对老旧代码做重构，目标不是“让覆盖率从 40% 拉到 80%”，而是“每次提交后，新写的逻辑覆盖率 ≥95%，且旧逻辑的排除范围有据可查”：
- CI 中不设全局覆盖率阈值，改为检查 diff 覆盖率（如使用
jest --coverage --changedSince=origin/main） - 每次 PR 提交时，自动报告本次修改涉及文件的语句/分支覆盖变化，重点看新增代码是否被覆盖、删减代码是否确实未执行
- 重构完成后，在文档中标明哪些旧模块已被移除、哪些被标记为 ignore、依据是什么（如 Coverage 录制证据、调用链分析截图）
