混淆工具不直接破坏Tree Shaking，但配置不当（如压缩导出名、提前删除未用导出、错误插入时机）会间接阻碍；需保持导出标识符不变、混淆置于摇树之后、禁用相关压缩选项。
混淆工具（如 Terser、UglifyJS）本身不会直接破坏 Tree Shaking，但若配置不当或代码写法不配合，会间接阻碍摇树生效。关键不在“混淆是否删代码”，而在于“混淆前的代码结构是否保留了可被静态分析的导出/引用关系”。
确保混淆不修改导出标识符名称
Terser 默认会对顶层作用域的变量名进行压缩（包括 export 的函数/变量名），一旦改名，Webpack 或 Rollup 就无法将 import { foo } from './utils' 与原始导出关联，导致无法识别未使用导出，进而跳过删除。
- Webpack + TerserPlugin：显式关闭
compress.module和mangle.module（v5.3+ 默认已关，但仍建议确认） - Rollup + terser：设置
module: true（Terser 选项），并确保mangle.properties.module为false - 避免手动开启
mangle: { module: true }—— 这会主动混淆 ES 模块导出名，直接废掉摇树
禁止混淆前移除未使用导出（no-drop-unused-export）
某些旧版混淆配置可能启用 drop_unused 类选项，让混淆器在打包前就删掉它认为“没被调用”的导出。这发生在模块图构建之前，会提前破坏导出完整性，使构建工具无法做正确依赖分析。
- Terser 中禁用
compress.drop_unused（默认为true，但对export语句影响有限；更关键的是确保不设compress.pure_getters = true等激进选项） - 明确添加
compress: { side_effects: false }不推荐——应由构建工具（如 package.json 的"sideEffects"字段）控制，混淆器不该越权 - 验证方式：构建后检查 dist 中的 bundle 是否仍保留未使用导出的
export function unused() { ... }结构（即使内容被压缩）
保持 ES 模块语法纯净，避免动态操作导出
混淆工具无法修复本就不利于摇树的写法。以下模式即使不混淆也会失效，混淆后更难挽救：
- 用
export * from './x'且目标模块无/*#__PURE__*/标注 → 摇树保守处理，倾向保留全部 - 导出对象解构赋值：
const { a, b } = utils; export { a, b }→ 构建工具难以追踪原始引用来源 - 运行时动态导出：
Object.keys(x).forEach(k => exports[k] = x[k])→ 完全无法静态分析，混淆与否都无效 - 解决方案：优先用具名导出、避免中间变量重绑定、不用
export *聚合大量模块
构建流程中混淆必须放在摇树之后
这是最基础也最容易被忽略的一点：Tree Shaking 是构建阶段（parse → analyze → prune → generate）完成的，混淆只是最后的代码压缩步骤。若混淆插件插入位置错误（例如在解析前或模块合并前运行），会破坏 AST 结构。
- Webpack：TerserPlugin 默认在
optimize-chunk-assets阶段运行，属于生成后压缩，符合要求 - Rollup：
terser()插件应置于plugins数组末尾，确保所有transform和renderChunk完成后再压缩 - 自定义流程（如 esbuild）：esbuild 的
treeShaking: true和minify: true是一体化设计，无需额外混淆，且默认安全
混淆不是摇树的敌人，而是需要对齐语义的协作者。核心原则是：让混淆只压缩实现细节，不扰动模块接口契约。只要导出名不变、导出结构可见、执行顺序合规，混淆和摇树就能共存无碍。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
