优化测试用例设计是识别、暴露并推动清理死代码的关键手段，需结合覆盖率分析、静态工具（如eslint）和人工验证三者协同，分阶段稳妥清理。
优化测试用例设计本身不能直接“消除”死代码，但它是识别、暴露并推动清理死代码的关键手段。真正清除冗余未覆盖的死代码，需要测试 + 工具 + 人工验证三者协同——测试是探照灯，不是清洁工。
用覆盖率驱动发现未执行的死代码
JS 测试框架（如 Jest）内置覆盖率报告，能精准标出哪些语句、分支、函数从未被执行：
- 运行
jest --coverage，查看./coverage/lcov-report/index.html，重点关注标红的行（未覆盖） - 特别留意：条件判断中永远走不到的
else分支、if (false)包裹的块、废弃的工具函数、调试用的console.log或debugger - 注意区分“真死代码”和“合理未覆盖”：比如仅在特定错误场景触发的兜底逻辑，若测试未模拟该异常，也会显示未覆盖，需人工判断是否应补测试，而非直接删除
写高价值测试，倒逼精简冗余逻辑
很多死代码源于过度设计或历史残留。通过测试用例反向约束实现，可自然淘汰无意义分支：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 每个测试用例应对应一个明确的业务契约，避免为“可能用到”的参数或状态写空分支
- 删掉没有对应测试的函数/方法——如果它不被任何测试调用，大概率也不被业务调用
- 对已有函数做“最小化重构”：先写覆盖其全部路径的测试（含边界、错误），再删掉测试未覆盖且语义模糊的逻辑（如
if (process.env.DEBUG)且无相关测试）
结合静态分析工具交叉验证
测试覆盖率反映“运行时未执行”，而静态分析工具能发现“编译时不可达”：
- 启用
eslint-plugin-unused-imports扫描未导入/未使用的模块、变量、函数 - 搭配
purgecss（配合 BEM 类名提取器）检查 JS 中硬编码的类名是否真实存在于模板/CSS 中 - 对疑似死代码，先查覆盖率 → 再跑 ESLint → 最后人工确认 JS 动态调用（如
el.classList.add('xxx')）、CSS Modules 导出、第三方库依赖等风险点
分阶段清理，避免误删
死代码清理必须稳字当头，尤其在中大型项目中：
- 第一阶段：清理高置信度项——如未被任何测试 import、未出现在覆盖率报告中、ESLint 明确报 unused 的独立工具函数
- 第二阶段：标记待观察项——如只在某个废弃页面中出现的组件方法，加
// TODO: remove after v2.0注释并监控 CI 是否报警 - 第三阶段：上线后验证——删除后观察 Sentry 错误日志、用户行为埋点，确认无异常调用
