你以为你用了 ES Module就自动开启 Tree Shaking 了很遗憾大多数情况下——并没有真正生效。很多项目打包后明明没用的代码还在bundle 体积异常膨胀优化了半天效果不明显问题很可能出在一个你没注意的地方package.json里的sideEffects先说结论别绕Tree Shaking 能不能真正生效不只取决于 ES Module还取决于打包器是否“敢删你的代码”。而sideEffects就是这个“信任开关”。sideEffects 到底是啥它是写在package.json里的一个字段{ sideEffects: false }它的含义是这个项目里的文件没有副作用可以安全删除未引用代码什么是“副作用”这是关键副作用的定义很简单执行这个模块时会对外部产生影响哪怕你没用它的导出有副作用的代码// utils.jsconsole.log(hello)// 会执行// theme.js document.body.style.background red// index.js import ./global.css // 会影响页面样式这些都属于“副作用模块”无副作用的代码exportfunctionadd(a,b){returnab} 纯函数 无全局修改 可安全删除为什么没有 sideEffects 就“摇不掉”打包器比如 Webpack在做 Tree Shaking 时会非常保守“我删了这个文件会不会出 bug”如果它无法确定宁可保留也不删除。结果就是import{a}from./utils// utils.jsexportconsta1exportconstbheavyFunction()即使b没用也可能被打进 bundlesideEffects: false 做了什么{sideEffects:false}等价于告诉打包器“放心删我的代码是纯的不会有隐藏影响”。实际效果未引用模块 → 被删除bundle 体积明显下降Tree Shaking 真正生效但这里有个坑很多人会踩你不能无脑写{ sideEffects: false }因为现实项目里通常会有CSSpolyfill初始化代码正确姿势工程推荐{ sideEffects: [ *.css ] }含义JS 可以被 Tree ShakingCSS 保留避免被误删。再讲一个更隐蔽的坑很多人不知道即使你写了sideEffectsTree Shaking 仍然可能失败常见原因1使用 CommonJSconstutilsrequire(./utils)无法做静态分析 → 直接失效2动态引用import(./${name}.js)路径不确定 → 无法分析3第三方库没写 sideEffects你写了没用它的代码还是不会被删总结你遇到以下情况时基本可以怀疑bundle 体积异常大Tree Shaking 看起来“没效果”引入 UI 库后体积暴涨而sideEffects就是这条链路里最容易被忽略、但影响最大的一个开关。