Tree Shaking 在团队中落地需从代码规范、协作流程和验证机制三方面同步推进；须统一ES6模块语法、禁用副作用、按需导出、正确声明sideEffects，并建立构建分析与PR体积监控闭环。
Tree Shaking 要在团队中真正落地，不能只靠工具配置，得从代码规范、协作流程和验证机制三方面同步推进。它不是“配好 webpack 就自动生效”的功能，而是需要开发者持续参与的工程习惯。
统一模块语法与导出方式
确保所有新代码和重构模块使用标准 ES6 import/export，禁用 require 和 module.exports。尤其注意以下几点：
- 工具函数库必须按需导出单个函数，避免
export default { add, subtract }这类对象聚合导出 - 禁止在模块顶层执行有副作用的操作（如修改 window、调用 console、发起请求）
- 组件或 Hook 导出要独立，不打包进一个大 index.js 再统一 re-export
- 第三方库尽量选用 ESM 版本（例如 lodash-es 而非 lodash）
标准化 package.json 的 sideEffects 声明
这是团队最容易忽略但影响最大的一环。sideEffects 字段告诉构建工具：“哪些文件可以安全地被摇掉”。必须明确声明，不能留空或设为 true。
- 纯工具库（无样式、无全局副作用）可直接设为
"sideEffects": false - 含 CSS、字体、SVG 等资源的包，列出具体路径，例如：
"sideEffects": ["*.css", "*.scss"] - 团队内部 UI 组件库建议每个子包单独维护
package.json，并各自声明 sideEffects - CI 流程中加入检查：禁止提交未声明 sideEffects 的新包
构建与验证闭环不可少
没有度量就没有改进。团队需建立可感知的反馈链，让 Tree Shaking 效果“看得见”：
- 每次构建后自动生成
stats.json，用source-map-explorer或webpack-bundle-analyzer可视化分析产物 - 在 PR 检查中加入体积阈值告警：比如某模块新增后，其打包后体积增长超过 5KB 就阻断合并
- 定期跑对比报告：对常用工具函数做“只 import 一个 API”测试，确认未使用函数是否真被剔除
- 文档沉淀常见失效场景（如动态 import、try-catch 中的 require、IIFE 包裹 export），作为新人必读项
关键不在于一次配对成功，而在于让每个成员写代码时自然想到“这个导出会被人摇掉吗”。当 import 成为选择，而不是惯性加载，Tree Shaking 就真正扎根了。
