清理废弃代码需结合chrome coverage定位未执行代码与webpack-bundle-analyzer验证tree shaking效果，辅以source map精准溯源、排除干扰项，避免误删间接引用或兜底逻辑。
清理废弃代码不能只靠肉眼判断，得结合运行时覆盖率数据和构建时静态分析双线验证。核心思路是：先用 Chrome Coverage 定位“加载了但没执行”的代码块，再回溯源码确认它是否真该被删；同时用构建分析工具（如 webpack-bundle-analyzer）交叉验证 Tree Shaking 是否生效，避免误删被间接引用的模块。
用 Chrome Coverage 面向运行时找“僵尸代码”
Coverage 不是测试覆盖率，而是页面实际执行痕迹的快照。它能直接告诉你哪些 JS/CSS 字节在当前访问路径中完全没亮过——这些就是最可疑的废弃候选。
- 打开 DevTools → More Tools → Coverage，或按 Cmd+Shift+P（Mac）/Ctrl+Shift+P（Win）输入 Show Coverage
- 点击录制按钮（●），刷新页面或完成关键交互（比如登录、切换 Tab、打开弹窗）
- 停止后查看列表：红色占比高的 JS 文件要重点盯——尤其是
utils.js、helpers/index.js这类工具集合文件 - 点击某文件，在 Sources 面板中逐行看：整段函数体全红？说明它从没被调用；某个
if分支内全红？可能对应已下线的功能逻辑
结合 source map 定位原始模块和导出项
如果构建时启用了 devtool: 'source-map'（推荐开发/测试环境开启），Coverage 能映射回未压缩的源码路径，而不是 bundle 里的一行乱码。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如 Coverage 显示
src/utils/date.js中parseISO函数全红，但formatDate是绿色 → 说明parseISO很可能已废弃 - 此时检查所有
import：是否还有地方写import { parseISO } from '@/utils/date'？如果没有，且 Git 历史显示该函数半年未被修改，基本可删 - 注意导出方式：
export * from './date'会阻止 Tree Shaking，Coverage 全红反而提示你该改成具名导入
用构建产物分析排除“假阳性”
Coverage 全红 ≠ 一定可删。有些代码虽未执行，却是按需加载或兜底逻辑（比如错误边界里的 fallback 渲染）。需用构建工具确认它是否还在最终包里。
- 运行
npx webpack-bundle-analyzer dist/stats.json（需先生成 stats 文件），看目标模块是否已从 bundle 中消失 - 如果模块在 bundle 分析图里压根没出现，Coverage 自然不会显示它——这才是 Tree Shaking 成功的信号
- 如果模块还在 bundle 里，且 Coverage 显示其 90%+ 为红色，就要查原因：是不是用了
require('module-' + name)动态引入？或是sideEffects: true拦住了剔除？
过滤干扰项，聚焦真实问题
别让无关文件拉低判断精度。在覆盖率配置中主动排除标准干扰源：
- Jest：在
jest.config.js加coveragePathIgnorePatterns: ['/node_modules/', '/dist/', '/src/main.ts', '/src/env.d.ts'] - nyc：在
.nycrc写"exclude": ["**/types/**", "**/*.test.js", "src/router/index.ts"] - 对确实难测的代码块（如 Node.js 专属逻辑、开发警告），加注释
/* istanbul ignore next */主动跳过，避免误判为废弃
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
