识别和清理死代码关键在判得准、删得稳，需结合工具扫描、语义理解与人工验证闭环：先用语言专属静态分析工具批量标记可疑点，再依结构规范（如bem）辅助精准定位，重点验证三类高风险依赖，最后分阶段清理高置信度项。
识别和清理死代码，关键不在“找得到”，而在“判得准、删得稳”。它不是简单删掉报错提示的几行，而是结合工具扫描、语义理解与人工验证的闭环过程。
用静态分析工具批量发现可疑点
不同语言生态有成熟且轻量的检测工具，它们能覆盖大多数典型死代码场景：
-
Python：用
vulture扫描未调用函数、未使用变量；搭配dead-master可识别注释块和模块级弃用项 -
PHP：
PHPStan和Psalm在类型分析过程中顺带标记不可达分支与未引用方法 -
JavaScript/TypeScript：
eslint-plugin-unused-imports+purgecss（配合 BEM 类名提取器）可定位 HTML/CSS/JS 中断连的样式与逻辑 -
Swift：
Periphery专精于跨文件调用图分析，比 Xcode 内置检查更彻底 -
Golang：编译器自带死代码消除（DCE），但需开启
-gcflags="-l -m"查看 SSA 阶段的活跃值判定日志
从结构规范入手，让死代码“自己暴露”
像 BEM 这类命名约定，本质是把作用域写进类名里。一旦组件下线，.card__header、.card--featured 就天然成组可删——工具能靠正则匹配精准捕获，人也能一眼看出归属。
实际操作中要配合两件事：
- 在
postcss-bem-linter中显式声明合法 Block 列表（如['button', 'card']），否则工具无法区分.icon是独立工具类还是.button__icon的缩写 - 用
purgecss的extractors配置，专门抓取__[a-z]和--模式，避免把.button--loading当普通字符串漏掉
重点验证三类高风险依赖，避免误删
看似孤立的代码，常被 JS 动态操作或 CSS Modules 导出消费。删之前必须确认：
- JS 中是否硬编码了该类名或函数名，例如
el.classList.add('button--disabled')合法，但el.className += ' disabled'危险——这个disabled不属于任何 Block，工具无法识别 - CSS Modules 是否导出了该修饰符：
import styles from './Button.module.scss'; console.log(styles['button--loading'])——若有，说明被 JS 显式消费，不能只看模板 - 是否与第三方库混淆，比如写了
.ant-btn__icon这种强行套 BEM 的类，既不生效又污染统计结果
分阶段清理，每次只动高置信度项
不要追求“一次清完”。推荐节奏：
- 第一轮：只处理工具标记为 100% 置信度的项（如函数定义后无任何调用、return 后的语句）
- 第二轮：对中等置信度项逐个查看调用链，用 CodeBuddy 的“查看调用链”功能确认是否真无入口路径
- 第三轮：运行清理命令后，立刻触发本地
git diff并人工抽检改动，尤其关注是否影响动态类切换或测试覆盖率
