识别和清理死代码关键在判得准、删得稳，需结合工具扫描、语义理解与人工验证闭环：先用语言专属静态分析工具批量标记可疑点，再依结构规范（如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 并人工抽检改动，尤其关注是否影响动态类切换或测试覆盖率