tree shaking 局部失效的主因是 commonjs 模块混入破坏静态分析，需确认 production 模式启用、识别 module.exports/require 痕迹、检查构建产物及工具链报告定位 cjs 模块。
Tree Shaking 局部失效，常见原因之一是项目中混入了 CommonJS 模块——它破坏了静态分析链，导致构建工具无法准确判断哪些导出未被使用。检查这类问题，关键不是“看有没有 require”，而是定位“哪段代码因 CommonJS 被引入，进而阻断了摇树传播”。
确认构建是否在生产模式下运行
Tree Shaking 默认仅在 production 模式启用。若 mode 为 development，即使全是 ES Module，也不会触发摇树。
- Webpack：检查 mode: 'production' 是否配置；可通过
webpack --env production显式指定 - Vite：build 命令默认 production；开发时（vite dev）不启用 Tree Shaking，无需检查
- Rollup：需确保
treeshake: true（默认开启），且未手动设为 false
识别 CommonJS 模块的典型痕迹
CommonJS 模块往往通过以下方式“悄悄混入”，并让其依赖的子模块失去可摇性：
- 第三方库主入口是
main字段（如"main": "index.js"），且内容含module.exports或require() - 你自己写的模块中用了
require('./utils')或const pkg = require('some-cjs-pkg') - Babel 配置中
@babel/preset-env启用了modules: 'commonjs'（会把import编译成require，彻底破坏 ESM 结构） - 某些插件（如旧版
babel-plugin-import）在处理 UI 库时，内部仍走require路径
用构建产物反向验证 CommonJS 影响
直接查看打包后文件，是最可靠的诊断方式：
- 打开最终 bundle（如
dist/assets/index.xxxx.js），搜索require(、module.exports、exports.等关键词 - 若发现某个你只用了其中一两个函数的工具库（比如 lodash），但 bundle 里出现了大量未调用的方法（
throttle、debounce、cloneDeep等全在），大概率该库是以 CommonJS 形式被引入的 - 对比改用
lodash-es后的 bundle 大小变化：若体积显著下降，说明原库是 CommonJS 阻碍了摇树
借助工具链定位源头模块
利用打包工具的统计能力，快速揪出“可疑 CJS 模块”：
- Webpack：启用
stats: 'verbose'或使用webpack-bundle-analyzer，观察模块类型列（Type）是否出现javascript/auto（代表 CommonJS）或javascript/dynamic - Vite：运行
vite build --report生成report.html，查看每个 chunk 的 “Module Type” 列，标为cjs的即为 CommonJS 模块 - Rollup：启用
output.sourcemap: true并配合rollup-plugin-visualizer，图中颜色偏红的模块常对应 CJS 或副作用保留
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
