自定义编译器插件自动剔除项目无用逻辑

在项目优化中，清理无用代码（Dead Code）始终是一个关键环节。许多开发者曾幻想能找到一种工具，像魔法般自动识别并删除所有冗余文件。然而现实往往更为复杂。以Webpack生态中知名的Deadcode Plugin为例，它的角色定位非常明确：一个精准的“扫描仪”，而非全自动的“手术刀”。它能帮助定位问题，但最终判断与执行删除的，仍然需要人工介入。

核心结论直接明了：不要指望任何插件能够“自动剔除”死代码。它们的作用是定位，真正的删除工作必须由人工判断和执行。

Webpack Deadcode Plugin只报告不删除，切勿期待其修改源码

该插件的设计初衷是在构建阶段进行静态分析，扮演尽职的“报告者”。它能清晰地指出src/utils/legacy-api.js文件未被任何模块导入，或者export const deprecatedHelper在整个依赖图中未被引用。然而，它仅止步于此——绝不会擅自改动任何一行源代码。

• 默认行为仅在终端输出警告信息。只有配置stats: "verbose"时，才会显示完整的未使用导出列表。
• 插件生成的JSON报告（例如deadcode-report.json）中，字段名为"unusedExports"和"unusedFiles"，不存在类似"autoRemoved"的字段。
• 即便设置failOnUnused: true导致构建失败，其原因也是“发现了死代码”，而非“删除代码失败”。

LLVM或Clang的DCE属于编译器级优化，与JS项目无关

部分人可能会联想到C/C++领域的编译优化。确实，像clang -O2中集成的GlobalDCEPass等工具，能在编译器层面直接删除未被调用的函数。但关键在于，其操作对象是LLVM中间表示（IR），而非.ts或.jsx文件。在Webpack配置中即便写入多个-O2也无济于事——那属于另一套语言体系的机制。

• 在JavaScript生态中，真正能在编译期进行激进死代码消除（DCE）的工具是Closure Compiler。它依靠@export注解、externs声明以及--compilation_level ADVANCED等配置，实现函数名重命名和未使用代码的移除。
• 更为常见的Terser（Webpack默认压缩器）主要进行语法树级别的压缩。它能删除诸如if (false) { ... }这样的明显无效分支，但对于整个未被引用的模块，则不会主动处理。
• 至于ESBuild，其treeShaking能力目前主要局限于对ESM静态import/export的分析。对于require()或动态import()等情况，基本无能为力。

真正可落地的自动化流程：报告 + 脚本 + PR检查

那么，如何高效利用这些扫描工具？正确的思路是将它们当作流程中的“守门员”，而非包办一切的“清洁工”。目标是将“发现死代码”这一动作转化为可重复、可审查、可协作的自动化流程。

• 集成到CI/CD：在持续集成环境中运行webpack --env production --stats=none --no-bail并启用Deadcode Plugin，将生成的JSON报告文件作为构建产物上传。
• 编写处理脚本：编写一个简单的Node.js脚本，读取deadcode-report.json，过滤掉node_modules和测试文件等干扰项，生成清晰的Markdown格式摘要。
• 触发代码审查：利用GitHub Actions等工具，在Pull Request中自动添加评论。例如，当检测到src/hooks/useLegacyAuth.ts中新出现未使用的导出时，自动链接到详细报告页面，提醒开发者审查。
• 关键补充验证：脚本本身不执行rm删除命令。更稳妥的做法是输出类似git ls-files | xargs grep -l "useLegacyAuth"的命令，帮助开发者二次确认该代码是否确实在任何地方均未被引用。

最后，有一个极易被忽略的盲区：动态引用。例如通过字符串拼接调用函数名（window[config.methodName]()），或利用反射机制遍历对象方法执行（Object.keys(obj).forEach(key => obj[key]())）。这类代码路径对于基于静态分析的插件而言是隐形的，因此必然会被漏报。所以，人工审查时绝不能只迷信报告中的文件列表，必须额外警惕这些动态模式，避免误删仍在生效的逻辑。