tree shaking的核心是剔除未使用的es module导出与模块，依赖静态分析而非独立功能；需确保esm语法、禁用commonjs转换、配置生产模式与sideeffects、结合产物分析工具定位残留，并排除类型导入、动态访问等干扰因素。
Tree Shaking 的核心目标是剔除未使用的导出（export）和未引用的模块，但它本身不是构建工具的独立功能，而是依赖 ES Module 静态结构 + 构建工具的死代码分析能力。所谓“捕获残留代码”，实际是指识别并定位那些本应被摇掉却仍保留在最终产物中的无用代码——这通常暴露了 Tree Shaking 未生效的原因。关键不在“捕获”而在“诊断与修复”，需结合构建配置、代码写法和产物分析三方面协同排查。
检查模块语法是否符合 ES Module 规范
Tree Shaking 只对 import/export 有效，CommonJS（require/module.exports）或动态导入（import()）会中断静态分析链：
- 确保所有依赖包本身使用 ESM 输出（查看其
package.json中的"type": "module"或"exports"字段）； - 避免混用
require和import，尤其在同一个文件中； - 禁用 Babel 的
@babel/preset-env对import/export的自动转换（设modules: false），否则会被转成 CommonJS，彻底关闭 Tree Shaking。
配置构建工具启用生产模式与副作用标记
以 Webpack 和 Vite 为例：
-
Webpack：确保
mode: 'production'，并显式设置optimization.usedExports: true（开启标记导出使用状态）； - 在
package.json中添加"sideEffects": false（全局声明无副作用），或精确列出有副作用的文件（如["*.css", "src/legacy-polyfill.js"]），否则 Webpack 会因保守策略保留整个模块； -
Vite 默认启用 Tree Shaking，但若用到
defineConfig({ build: { rollupOptions: { ... } } })，需确认未误配treeshake: false；同时检查插件（如 legacy 插件）是否引入了非 ESM 兼容逻辑。
利用产物分析工具定位残留代码源头
仅靠肉眼无法判断哪段代码“该删没删”，需借助可视化手段：
- Webpack：启用
stats: 'verbose'并配合webpack-bundle-analyzer插件，生成交互式模块关系图，点击具体 chunk 查看哪些export被标记为unused harmony export xxx—— 若未出现该提示，说明未触发分析； - Vite：运行
vite build --report生成report.html，或加--debug查看 Rollup 的 treeshaking 日志（如TREE_SHAKING_LOG=1 vite build）； - 手动验证：在源码中添加一个明显无用的命名导出（如
export const DEAD_CODE = () => console.log('never called');），构建后搜索产物中是否还存在该字符串，若存在即说明对应模块未被摇掉，再回溯其导入链。
警惕常见干扰因素
以下情况会让代码“看似残留”，实则合理或需额外处理：
-
默认导出（
export default）未被引用时，部分工具仍保留整个模块：改用具名导出（export const foo = ...）更利于精确摇取； -
类型导入（TypeScript）未被剥离：确保
tsconfig.json中"importsNotUsedAsValues": "error"或"remove"，并由构建工具（如 esbuild/vite）负责擦除，而非仅靠 TS 编译； -
第三方库内部使用了
eval、with或 try-catch 访问属性（如obj[process.env.FEATURE]），Rollup/Webpack 会放弃对该模块做深度摇取，此时需通过/*#__PURE__*/注释标记纯函数调用，或改用编译时确定的条件分支。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
