tree shaking 无法消除模块内部互引的“死代码”，因 esm 静态分析仅识别 import/export 语法，无法判断 funcb/c 是否仅被 funca 内部调用，故保守保留整个调用链；优化需切断导出暴露，如拆分私有模块、统一命名导出、启用 innergraph 或 modulesideeffects 等配置。
Tree Shaking 无法消除模块内部互相引用产生的“死代码”，根本原因是：ESM 的静态分析要求导出必须被标记为 可能被外部使用，而模块内相互调用会形成闭包依赖链，导致打包器（如 Webpack、Rollup）保守地保留全部导出项。
为什么内部互引会阻碍 Tree Shaking
当一个模块中多个函数/变量彼此调用（例如 funcA 调用 funcB，funcB 又调用 funcC），即使最终只从外部导入了 funcA，打包器也无法确认 funcB 和 funcC 是否仅被 funcA 使用——它们可能还被其他未分析到的动态逻辑（如 eval、require()、运行时属性访问）间接引用。因此，为保证正确性，整个调用链会被保留。
- ESM 静态分析只看
import/export语法，不执行代码，无法做控制流分析（CFG） - 模块级导出是“原子单位”：只要某个导出被引入，该模块所有顶层导出声明都可能被标记为“活跃”
- 如果
funcB同时被funcA和外部模块导入，它就不能被剔除；打包器无法区分“内部专用”和“公共可用”
可行的优化策略
绕过限制的关键是**切断不必要的导出暴露**，让工具能明确识别“哪些确实没被用”：
-
拆分模块：把仅供内部调用的辅助函数移到独立的私有模块（如
utils/internal.js），不对外导出，仅在主模块中import使用 —— 这样它们不会出现在 ESM 导出图中 - 避免默认导出 + 命名导出混用：统一用命名导出，并确保每个导出只被显式 import；默认导出容易隐藏依赖关系，影响分析精度
-
启用更激进的配置：Rollup 中设置
treeshake.moduleSideEffects: false（需确认模块无副作用），Webpack 5 开启optimization.innerGraph: true（增强内部引用图分析） -
用
/*#__PURE__*/标记无副作用调用：对确定不会产生副作用且只用于计算的内部调用加注释，帮助压缩器（如 Terser）进一步删除未使用的返回值或调用
检查是否生效的小技巧
不要只信 bundle 大小数字，要验证实际删减效果：
- Webpack 用户可加
stats: "verbose"并搜索unusedExports字段 - Rollup 用户启用
treeshake: { logs: true }，构建时会打印被移除的语句 - 生成 sourcemap 后用 webpack-bundle-analyzer 查看具体哪些函数仍保留在 chunk 中
核心原则是：Tree Shaking 不是智能 AI，它只响应你写的 import/export 结构。想让它工作，就得让代码的依赖关系足够“静态”和“透明”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
