解构构建过程：树摇（Tree-Shaking）的实际工作原理（以及为何打包结果至关重要）

你好，开发者社区！👋

在我们关于 YMS 迁移（从 Angular 16 到 21）系列文章的第一篇中，我提到放弃 app.module.ts 并采用独立组件的最大胜利之一，就是树摇优化得到了显著改善。

理论固然好，但在我们的领域，数据才是王道。在这次结构重构过程中，通过移除模块、清理未使用的文件以及调整遗留逻辑，我们成功将构建文件夹的大小从惊人的 40MB 减少到约 15MB。系统“体积”减少了超过 60%！

作为开发者，我们喜欢了解底层机制是如何运作的，因此我决定暂时中断主线系列文章，来深入剖析这一过程。框架究竟是如何从我们的项目中剔除 25MB 的“冗余脂肪”的？

答案归结为两点：新的打包工具（Esbuild/Vite）和终于变得高效的树摇优化。但在我们摇晃这棵树之前，我们需要确切理解我们要发送给用户浏览器的“水果篮”究竟是什么。

打包文件（或称捆绑包）是 Angular 构建过程的最终产物。

当你编写 YMS 代码时，你会创建数百个（在一个五年的项目中甚至数千个）TypeScript、HTML 和 CSS 文件。但是，用户的浏览器并不理解 TypeScript，也不知道如何加载这种复杂的文件夹结构。

打包工具的作用是读取所有这些代码，对其进行处理，将其编译为原生 JavaScript，并将所有内容合并为一个（或少量几个）文件。正是这个单一的包被浏览器下载并执行，从而运行你的系统。

打包文件的大小对开发者体验（DX）和用户体验（UX）都有直接且巨大的影响：

构建速度：在开发过程中，较小的打包文件意味着热重载（保存文件时在屏幕上看到更改）几乎是瞬时的，这极大地提高了我们的生产力。
初始加载时间：对于用户而言，较小的打包文件意味着更快的下载速度。如果你的 YMS 拥有一个数十兆字节的包，用户将不得不长时间面对白屏，尤其是在移动网络或物流仓库不稳定的连接环境下。
解析和执行时间：浏览器不仅要下载文件，还需要解释和执行所有 JavaScript 代码。较大的文件会消耗更多的中央处理器资源和时间，可能导致界面卡顿，造成糟糕的体验。

简而言之：打包文件是运行你系统的最终文件，其大小决定了应用程序的速度。在企业级系统中，优化它是一项绝对优先的任务。

想象你的项目是一棵果树。树干是你的 main.ts，树枝是你的组件、服务和外部库（如 PrimeNG 或 RxJS）。树叶则是代码中编写的函数和方法。

当到了将该项目部署到生产环境（即构建时刻）时，你的打包工具会用力摇晃这棵树。目的是什么？让所有枯叶（你编写或从库中导入但从未在界面上实际使用的代码）掉落在地上，而不被发送

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。