webpack deadcode plugin 仅能定位死代码而无法自动删除，它只在构建时扫描并报告未使用文件与导出，不修改源码；真正删除需人工判断并操作。
不能靠插件“自动剔除”死代码——它只能帮你定位，真正删还得人来判、人来动。
Webpack Deadcode Plugin 只报不删，别指望它改源码
这个插件本质是构建时的“扫描仪”，不是“手术刀”。它能列出 src/utils/legacy-api.js 没被任何模块 import，也能指出 export const deprecatedHelper 在整个依赖图里零引用，但不会碰你一行源文件。
- 默认行为只在终端输出警告，
stats: "verbose"才显示完整未使用导出列表 - 生成的 JSON 报告（如
deadcode-report.json）里字段是"unusedExports"和"unusedFiles"，没有"autoRemoved"这种字段 - 如果你配了
failOnUnused: true，构建会失败，但失败原因只是“发现死代码”，不是“删除失败”
LLVM 或 Clang 的 DCE 是编译器级优化，和 JS 项目无关
像 clang -O2 自带的 GlobalDCEPass 确实能删掉未调用的 C 函数，但它作用对象是 LLVM IR，不是你的 .ts 或 .jsx。你在 Webpack 里配再多个 -O2 也没用——那是给 C/C++/Rust 用的。
- JS 生态里真正做编译期 DCE 的是 Closure Compiler，靠
@export+externs+--compilation_level ADVANCED实现函数重命名+未使用移除 - Terser（Webpack 默认压缩器）只做语法树级压缩，
if (false) { ... }会被删，但整个未引用的模块不会动 - ESBuild 不做跨文件 DCE，它的
treeShaking仅限于 ESM 静态 import/export 分析，对require()或动态import()无能为力
真正能落地的自动化流程：报告 + 脚本 + PR 检查
把插件当守门员，而不是清洁工。重点是让“发现死代码”变成可重复、可审查的动作。
- 在 CI 中运行
webpack --env production --stats=none --no-bail+webpack-deadcode-plugin，把 JSON 报告上传到 artifact - 写个简单 Node 脚本读取
deadcode-report.json，过滤掉node_modules和测试文件，生成 Markdown 摘要 - 用 GitHub Actions 触发 PR 评论：检测到新出现的未使用导出
src/hooks/useLegacyAuth.ts，链接到报告详情 - 关键点：脚本不执行
rm，只输出git ls-files | xargs grep -l "useLegacyAuth"帮你确认真没人用
最常被忽略的是动态引用场景——比如通过字符串拼接调用函数名 window[config.methodName]()，或者用 Object.keys(obj).forEach(key => obj[key]())。这类代码即使完全没被静态分析捕获，也会被插件漏掉。人工 review 时得盯住这种模式，而不是只看插件报告里的文件列表。
