webpack tree shaking 生效的关键是防止副作用干扰静态分析，需通过 package.json 的 sideeffects 字段声明、避免顶层副作用代码、使用具名导入、选用纯 es 模块库，并在 production 模式下构建验证效果。
要让 Webpack 的 Tree Shaking 真正生效，关键不是“开了就行”，而是防止副作用干扰静态分析——一旦模块被判定有副作用，整个文件都会被保留，哪怕只用了一个函数。
明确声明模块是否含副作用
在项目根目录的 package.json 中设置 sideEffects 字段，这是最直接的控制方式：
- 若项目所有 ES 模块都纯（无全局修改、无样式注入、无 polyfill 执行），写
"sideEffects": false - 若只有个别文件有副作用（如
src/polyfill.js或styles/index.css），则显式列出："sideEffects": ["./src/polyfill.js", "./styles/**/*.css"] - 注意路径必须匹配实际导入路径，且支持 glob 模式；CSS 文件需确保 loader 正确处理，否则仍可能被误删
避免顶层副作用代码
Tree Shaking 依赖静态可分析性。只要模块顶层存在运行时行为，Webpack 就不敢删它：
- 不要在工具模块里直接调用
fetch()、修改window、绑定事件或执行console.log() - 把副作用逻辑移到函数内部，例如把初始化操作封装成
init()，再按需调用 - 像
lodash这类库若含副作用（如自动 polyfill），优先换用lodash-es—— 它是专为 Tree Shaking 设计的 ES 模块版本
用对导入方式，不破坏静态结构
即使配置正确，错误的写法也会让 Tree Shaking 失效：
- 禁止全量导入：
import _ from 'lodash'→ 即使只用_.debounce，整包也被保留 - 改用具名导入：
import debounce from 'lodash-es/debounce'或import { debounce } from 'lodash-es' - 组件库如 Ant Design，配合
babel-plugin-import或直接使用 es 目录路径（antd/es/button），避免加载未用组件及其样式
验证与持续监控
优化不是一劳永逸，得靠工具确认效果：
- 构建后用
source-map-explorer可视化分析产物，定位哪些模块没被摇掉 - 检查打包日志中是否有
[unused exports]提示，这是 Webpack 标记但未删除的部分 - 确保构建在
mode: 'production'下运行 —— development 模式默认不启用删除逻辑，只做标记
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
