Tree Shaking是一种基于ES Module静态分析的依赖优化技术，通过构建模块依赖图谱，在编译时识别并移除未被引用的“死代码”，从而减小打包体积。它与传统压缩工具不同，属于模块级别的精准剔除，需依赖ESM语法、正确配置sideEffects和Babel的modules选项，并结合现代打包工具在生产模式下实现最佳效果。
JavaScript的模块化中的Tree Shaking原理，本质上是一种依赖优化技术，它通过静态分析，在代码打包过程中识别并移除那些在项目中从未被实际引用和使用的代码（即“死代码”）。核心在于，它不是在运行时判断代码是否被执行，而是在编译时，通过ES Module（ESM）的静态导入/导出特性，构建模块间的依赖图谱，从而精确地“摇掉”无用的部分，达到减小最终打包文件体积的目的。
解决方案
要深入理解Tree Shaking，我们得从ES Modules说起。CommonJS模块（Node.js里常用的
require
/
module.exports
）是动态加载的，你可以在运行时根据条件决定
require
哪个模块，这使得静态分析变得非常困难，几乎不可能预判哪些代码会被使用。但ES Modules不同，它的
import
和
export
语法是完全静态的。这意味着，在代码执行之前，打包工具就能清晰地知道一个模块导出了什么，以及另一个模块从它那里导入了什么。
Tree Shaking就是利用了ESM的这个特性。当你的项目使用Webpack、Rollup或Vite这样的现代打包工具时，它会做几件事：
构建依赖图谱： 打包工具会从你的入口文件开始，解析所有的
import
和
export
语句，构建一个完整的模块依赖关系图。它知道哪个文件导出了哪些具体的变量、函数或类，以及哪个文件又导入并使用了它们。标记被使用代码： 在这个图谱中，打包工具会遍历所有模块，标记出所有被实际导入和使用的代码块。如果一个模块导出了
funcA
和
funcB
，但你的项目只
import { funcA } from './module'
，那么
funcA
就会被标记为“used”。移除未引用代码： 那些被导出但从未被任何地方
import
并使用的代码，或者虽然被
import
了但最终在代码逻辑中没有任何实际调用的部分，就会被识别为“死代码”。在最终生成打包文件时，这些死代码会被直接删除，就像从树上摇落枯叶一样。
这个过程的关键在于“静态分析”，它不需要运行代码，只看代码的结构。所以，如果你的代码写得足够模块化，并且没有太多难以分析的副作用（side effects），Tree Shaking的效果就会非常显著。
立即学习“Java免费学习笔记（深入）”；
Tree Shaking与传统代码优化的区别何在？
我个人觉得，很多人会把Tree Shaking和传统的代码压缩（Minification）混为一谈，但它们其实是两个层面的事情，虽然目标都是减小文件体积，但手段和侧重点大相径庭。
传统的代码压缩，比如使用UglifyJS或Terser，主要做的是“瘦身”工作。它会：
移除空白字符和注释： 这是最基础的。缩短变量名和函数名： 把
veryLongFunctionName
变成
a
或
_1
。进行简单的死代码消除： 比如在一个函数内部，如果有一个
if (false)
的代码块，它会被移除。但这通常只局限于单个文件或非常简单的跨文件场景。
而Tree Shaking，它的核心能力在于模块级别的死代码消除。它不是简单地缩短名字或移除空格，而是识别并删除整个未使用的模块导出。想象一下你引入了一个大型UI组件库，但你只用了其中的一个按钮组件。传统的压缩工具可能会压缩按钮组件的代码，但它无法知道你没有使用其他几百个组件，所以那些未使用的组件代码依然会留在你的打包文件里。Tree Shaking则能做到这一点，它会“摇掉”那些你没用到的组件代码，只留下你真正需要的。
所以，它们是互补的。Tree Shaking在打包阶段进行，它首先将无用的模块代码剔除。之后，压缩工具再对剩下的、真正被使用的代码进行进一步的“瘦身”，两者结合才能达到最佳的优化效果。可以说，Tree Shaking是“精准截肢”，而代码压缩是“全身塑形”。
哪些因素会影响Tree Shaking的效果？
说实话，这玩意儿配置起来，有时真让人头大，一个不小心，可能就白忙活了。Tree Shaking的效果好坏，受到几个关键因素的制约：
ES Modules的使用： 这是基石。如果你的项目还在大量使用CommonJS模块（例如，很多老旧的npm包可能还是CommonJS），那么Tree Shaking就很难发挥作用。打包工具无法对动态的
require
进行静态分析。所以，尽可能使用ESM语法进行导入导出是前提。副作用（Side Effects）的声明： 这是最容易踩坑的地方。有些模块在被导入时，即使没有显式地使用其导出的内容，也可能会产生副作用，比如修改全局变量、注册全局事件监听器，或者在模块初始化时执行一些操作。对于这类模块，打包工具为了安全起见，通常不会轻易将其移除。你需要在
package.json
中通过
"sideEffects": false
（表示整个包都没有副作用，可以安全地进行Tree Shaking）或指定一个数组（表示只有这些文件有副作用，其他文件可以Tree Shaking）来明确告知打包工具。如果忘记声明或者声明错误，可能会导致不该被移除的代码被移除，或者该被移除的代码没被移除。Babel的配置： 如果你的项目使用了Babel进行代码转译，需要特别注意
@babel/preset-env
的配置。如果将其中的
modules
选项设置为
"commonjs"
（这是Babel 7之前的默认值，现在默认是
false
，即不转换模块），Babel会把ESM语法转译成CommonJS，这样打包工具就无法进行Tree Shaking了。确保
modules
设置为
false
，让打包工具去处理ESM。代码结构和编写习惯： 编写纯函数、避免全局状态修改、将逻辑清晰地拆分成小模块，这些都有助于Tree Shaking。如果一个模块内部包含大量难以分析的复杂逻辑，或者一个导出依赖于另一个复杂的、有副作用的导出，那么Tree Shaking的精准度就会下降。打包工具的版本和配置： 确保你使用的打包工具（如Webpack 4+、Rollup、Vite）是最新版本，并且在生产模式下正确配置了Tree Shaking。通常，这些工具在生产模式下会自动启用Tree Shaking，但了解其内部机制和配置选项仍很重要，比如Webpack的
optimization.usedExports
和
optimization.sideEffects
。
如何在项目中有效利用Tree Shaking，提升应用性能？
这不仅仅是技术活，更是一种开发习惯的养成。从一开始就考虑模块化和副作用，能省去后面很多麻烦。要充分利用Tree Shaking，可以从以下几个方面入手：
拥抱ES Modules： 尽可能在你的所有JavaScript代码中使用
import
和
export
语法。对于第三方库，如果它们提供了ESM版本，优先选择使用。编写纯净、模块化的代码： 尽量将每个模块设计成单一职责，减少模块间的隐式依赖和副作用。纯函数（给定相同的输入，总是返回相同的输出，且没有副作用）是Tree Shaking的理想对象。正确声明
sideEffects
： 对于你自己的库或者你开发的复杂模块，务必在
package.json
中正确配置
"sideEffects"
字段。
{ "name": "my-library", "version": "1.0.0", "sideEffects": false, // 表示整个库都没有副作用，可以安全地进行Tree Shaking // 或者 "sideEffects": [ "./src/global-styles.js", // 只有这个文件有副作用，其他文件可以摇掉 "*.css" // 所有CSS文件都有副作用 ]}
这告诉打包工具哪些文件是不能随便删除的。
审查Babel配置： 确认
@babel/preset-env
的
modules
选项没有将ESM转译成CommonJS。通常，在Webpack等打包工具环境中，应该将其设置为
false
或不设置（默认就是
false
）。
// .babelrc 或 babel.config.js{ "presets": [ ["@babel/preset-env", { "modules": false // 保持ESM语法，让打包工具处理 }] ]}
使用现代打包工具： Webpack 4及以上版本、Rollup或Vite都对Tree Shaking有很好的支持。确保你的项目配置了生产模式，因为Tree Shaking通常是在生产构建中进行的。监控和分析： 使用Webpack Bundle Analyzer或类似的工具，可视化你的打包文件内容。这能帮你直观地看到哪些模块占用了大量空间，哪些代码可能没有被Tree Shaking掉，从而有针对性地进行优化。选择对Tree Shaking友好的库： 在选择第三方库时，可以考虑那些明确声明支持Tree Shaking的库。它们通常会提供ESM版本，并且正确配置了
sideEffects
。
通过这些实践，我们不仅能减小最终的JavaScript包体积，加快页面加载速度，还能培养更好的模块化开发习惯，让代码更易于维护和理解。
以上就是什么是JavaScript的模块化中的Tree Shaking原理，以及它如何通过静态分析消除未引用代码？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/59989.html
微信扫一扫 
支付宝扫一扫 
