JavaScript如何实现Tree Shaking？为何能减小体积？

Tree Shaking 是现代前端构建中至关重要的体积优化技术，它并非运行时机制，而是依赖 ES 模块静态语法（export/import）在打包阶段精准识别并剔除未使用代码的死代码消除过程；其生效前提严格而关键：必须全程采用命名导出、禁用动态导入、确保第三方库提供真正的 ESM 支持（如 lodash-es 而非 lodash），并在构建配置中正确启用优化与副作用声明——稍有不慎（如混用 CommonJS、默认导出大对象或遗漏 sideEffects 配置），整个 Tree Shaking 链路就会失效，导致大量冗余代码悄然进入生产包。

Tree Shaking 依赖 export 和 import 的静态结构

Tree Shaking 不是运行时行为，而是打包工具（如 Webpack、Rollup、Vite）在构建阶段基于 ES 模块的静态导入导出语法做的死代码消除。它能工作，前提是模块使用的是 export / import，而不是 module.exports 或 require() —— 后者是动态的，无法在编译期确定依赖关系。

常见错误现象：import { something } from './utils.js' 却在文件里用 module.exports = { fn: () => {} }，此时 Tree Shaking 失效，整个 utils.js 都会被保留。

• 确保所有库和你自己写的模块都用 export 导出（命名导出优先于默认导出，更利于按需提取）
• 避免在 import 后做动态操作，例如：const mod = await import('./' + name) 或 import('./a').then(...)，这类动态导入无法被 Tree Shaking 分析
• Vite 默认启用，Webpack 5+ 需确认 mode: 'production' 且 optimization.usedExports: true

为什么 export default 有时会阻碍 Tree Shaking

当模块只用 export default 导出一个对象（比如 export default { a: 1, b: 2 }），打包工具往往无法安全地判定哪些属性没被使用，于是整个对象都被保留。相比之下，命名导出（export const a = 1; export const b = 2;）能让工具精确标记每个绑定的引用状态。

示例对比：

/* utils.js */
// ❌ 不利于 Tree Shaking
export default {
  format: () => {},
  parse: () => {},
  validate: () => {}
};
// ✅ 推荐：命名导出，可单独摇掉未用函数
export const format = () => {};
export const parse = () => {};
export const validate = () => {};

使用时也对应改写：import { format } from './utils.js' 而非 import utils from './utils.js'; utils.format。

第三方库是否支持 Tree Shaking 取决于它的导出方式

很多 npm 包（如 lodash）默认不支持，因为它们导出的是一个大对象或使用 CommonJS；但提供 ESM 版本的（如 lodash-es）就支持。使用前务必检查包的 package.json 中是否有 "module": "dist/index.esm.js" 字段，以及源码是否为命名导出。

• lodash → 不支持（CommonJS 主入口）；lodash-es → 支持（ESM 命名导出）
• date-fns → 支持（每个函数独立导出，import { format } from 'date-fns' 可摇掉其余）
• moment → 几乎不支持（全局对象 + CommonJS，即使只引入一个函数也会带入整个 locale 数据）
• 若必须用不支持的库，可尝试插件如 babel-plugin-lodash 或手动指定路径：import debounce from 'lodash/debounce'

开发时容易忽略的“假摇”陷阱

看起来代码没被引用，却仍被打包进去？常见原因不是 Tree Shaking 失效，而是副作用（side effects）被保留。Webpack 把 exports 标记为有副作用的模块（比如影响全局变量、修改原型、调用 console）时，默认不删——哪怕你只 import 了其中一两个函数。

解决方法：

• 在库的 package.json 中声明 "sideEffects": false（表示无副作用），或显式列出有副作用的文件（如 ["*.css"]）
• 自己的项目中，确保工具函数不产生意外副作用：避免在顶层执行 Array.prototype.myMethod = ... 或 console.log('init')
• 用 webpack --display-used-exports 查看哪些导出被标记为 “used”，辅助定位“为何没被摇掉”

真正起作用的不是“写了 import 就能摇”，而是整个链路——从你的 import 写法、库的导出形式、打包配置的副作用策略，到最终生成的 chunk 分析，缺一不可。

今天关于《JavaScript如何实现Tree Shaking？为何能减小体积？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！