babel 是 tree shaking 失效的常见“幕后推手”，因其默认将 import/export 编译为 require/module.exports，破坏静态分析；关键需设 modules: false 并验证产物中仍存在 import/export 关键字。
Tree Shaking 失效时，Babel 是最常被忽略的“幕后推手”——它本该保留 ES 模块结构，却可能在转译过程中悄悄把 import 编译成 require()，直接切断静态分析链。排查关键不是看 Babel 配置多漂亮，而是验证它是否真正放行了 ESM 语法。
检查 Babel 是否破坏了 ESM 静态结构
Babel 默认会把 ES 模块语法降级为 CommonJS（尤其在旧 preset 下），导致 Webpack 无法做静态依赖分析。核心判断标准只有一条：打包产物里是否还存在 import/export 关键字。
- 打开
node_modules/@babel/preset-env的配置，确认modules选项显式设为false（不是undefined或"commonjs"） - 若使用
@babel/preset-typescript，需额外加onlyRemoveTypeImports: true，否则 TypeScript 类型导入可能干扰导出识别 - 临时禁用所有 Babel 插件，仅保留
babel-loader基础配置，重新构建并检查 dist 中的 JS 文件——如果此时 Tree Shaking 恢复，就坐实是某个插件动了模块结构
识别高危 Babel 插件组合
有些插件看似无害，实则会间接污染模块纯度或引入动态行为：
-
@babel/plugin-transform-runtime：若开启useESModules: false（默认值），会把辅助函数包装成 CJS 形式，阻断导出追踪 -
@babel/plugin-proposal-decorators（legacy 模式）：装饰器编译后常生成带副作用的类初始化代码，触发sideEffects保守保留逻辑 - 自定义 polyfill 插件（如手动注入
core-js）：若在模块顶层执行require('core-js')，会被视为有全局副作用，整块模块无法被摇掉
用构建产物反向验证 Babel 行为
不依赖猜测，直接看编译输出：
- 在 Webpack 配置中启用
stats: "verbose"，构建后搜索compilation.modules，观察源文件是否仍以HarmonyModule类型存在；若显示NormalModule或CachedModule，说明已被转为非 ESM 模块 - 在 dist 文件中搜索
/* unused harmony export注释——这是 Webpack 标记未使用导出的关键证据；若完全找不到，大概率是 Babel 提前把export消掉了 - 用
webpack-bundle-analyzer查看模块图谱，对比开启/关闭babel-loader时./src/utils.js这类工具模块是否始终出现在图中（即使没被引用）
本质上，Babel 在 Tree Shaking 里只该做一件事：转语法，不动模块形态。只要它让 import 和 export 安然抵达 Webpack，后续优化就能自然发生。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
