手把手教 | Angular构建优化 | 看完就会写

▌ 技术引导

我见过太多人用Angular构建项目，动不动就打包半天，还觉得是正常现象。其实不然，Angular本身就有构建优化的武器，你只要稍微了解一些，就能把构建时间砍掉一半。别跟我说你不会用Angular CLI，这玩意儿0.5版本开始就内置了生产环境构建模式，你只要加个--prod参数就能开启。但不只是这个，还有更狠的，比如tree-shaking、Ahead-of-Time (AOT)编译、懒加载模块，这些都不是魔术，而是真实能落地的技术。我还见过有人在打包后发现体积爆炸，后来才知道是没用Angular的优化工具，比如ng-packagr，或者没开启code splitting，导致所有代码一股脑儿打包。你要知道怎么配置这些工具，才能真正让构建快起来、体积小下去。

别以为构建优化就是改个参数，它涉及到你项目的结构、模块划分、依赖管理、环境变量配置，以及打包策略。我之前在做一个中大型项目，用了AOT和lazy loading，构建时间从原来的10分钟降到3分钟，而且体积还少了40%。关键在于你怎么组织模块，怎么用Angular的优化工具。如果你不懂这些，你只是在用框架，而不是在用框架的生产力。控制构建时间、减少输出体积、提升首屏加载速度，这些都需要你手动配置，不是框架会自动给你搞好。

你要是还用着默认的构建配置，那你的项目在生产环境下可能在运行的时候就已经开始卡顿。我见过很多项目在开发模式下跑得飞起，但到了生产模式，资源加载就变得像老式电脑一样卡。Angular的构建优化不是简单的开关，你需要了解它用的是什么工具，如何配置，以及背后逻辑。比如，AOT不是简单的编译，它会提前将组件编译成JavaScript，减少运行时的解析时间。而tree-shaking是Webpack的特性，但Angular让你用更简单的命令就能触发它。你要是不把这些用起来，那你就是在浪费框架的潜力。

而且，优化还得看你的实际需求。比如，如果你用的是服务端渲染（SSR），那构建优化又会有所不同。你得用Angular Universal，配合Angular CLI的server构建命令，这样就能更好地优化服务端的打包配置。还有，如果你用到了第三方库，比如Lodash、RxJS，那你得考虑是否需要使用Angular的包优化策略，比如用Angular Package Format或者配置Webpack的tree-shaking规则。总之，构建优化不是一劳永逸的事，它需要你了解框架的底层设计，并根据项目具体情况来调整。

▌ 技术参考

一 技术背景与核心概念
Angular的构建优化基于Webpack和TypeScript编译器。生产环境构建会启用tree-shaking，清除未使用的代码；同时默认开启AOT，减少运行时解析负担。你还可以通过Angular CLI的构建命令配置code splitting，将功能模块按需加载。这些优化背后，都是对代码结构、依赖关系的深度分析。比如，使用AOT时，Angular会生成静态的JavaScript文件，而不用等待运行时编译。这极大降低了首屏加载时间，尤其对移动端和低性能设备影响显著。但AOT并不是万能，它需要你把组件写得更规范，否则会有各种警告和错误。例如，如果你有动态导入或者某些元数据依赖，AOT可能会报错，这时候你得用ng-packagr或自定义Webpack配置来解决。

二 具体操作方法或配置步骤
构建生产环境包的命令是 `ng build --configuration=production`。这个命令会应用所有默认的优化策略，包括AOT、tree-shaking和代码分割。如果你想更细粒度地控制，可以在angular.json中配置不同环境的构建参数。例如，添加 `--prod` 选项可以触发所有优化，而 `--aot` 能强制开启AOT编译。你还可以通过 `--output-hashing=media` 来优化资源哈希策略，让缓存更高效。如果项目结构复杂，建议使用Angular CLI的 `ng build --configuration=production --stats-json` 来输出构建统计信息，帮助你识别哪些模块体积过大，甚至哪些代码被错误地保留下来。这个统计文件能让你直接看到未被tree-shaking的代码片段，帮你排查问题。

三 常见踩坑场景与避坑方案
我见过最多的问题是，构建后的体积和预期不符，甚至比开发环境更大。这通常是因为没正确配置Webpack的tree-shaking规则，或者某些第三方库被错误地打包进去。比如，如果你用的是RxJS，它默认会引入整个库，但你可以用按需加载的方式，这样体积能大大减少。如果你在构建时遇到AOT编译错误，那可能是组件中用了某些动态元数据，这时候你得检查代码是否有 `@ngneat/until-destroy` 或 `@angular/core` 的 `ɵɵdefineComponent` 方法被误用。另外，如果你发现打包后的文件名包含 `main` 或 `polyfills`，那可能是没正确配置dynamic imports，导致所有代码打包到同一个文件中。这时候，你可以考虑使用Webpack的splitChunks插件，或者用Angular的 `--build-optimizer` 参数来优化。

四 性能影响或效率对比
对比开发模式和生产模式，构建时间差异非常显著。比如，一个常规的Angular项目，在开发环境下构建可能需要2-5分钟，但在生产模式下，时间通常会减少到30秒到2分钟。这主要得益于AOT编译和tree-shaking的优化。而且，生产环境下的文件体积通常能减少40%以上，特别是当使用懒加载和代码分割时。比如，在一个使用懒加载的项目中，首屏加载体积可能从3MB降到1MB，因为其他模块被拆分成单独的文件。这种优化直接影响用户体验，尤其是首屏渲染速度。不过，优化后的代码有时候会更难调试，因为AOT生成的代码会把组件信息编译成静态结构，不像开发环境那样动态生成。

五 适用场景与局限性
构建优化适用于所有需要上线的Angular项目，尤其是中大型项目和需要首屏加载快的场景。如果项目结构简单，或者你希望快速上线，可能不需要做太多优化。但如果你希望提升性能、减少资源消耗、加快部署速度，那你必须用上这些技巧。不过，构建优化也有其局限性，比如AOT会增加构建时间，特别是在项目第一次构建时；另外，tree-shaking对某些动态导入或第三方库支持有限，你可能需要手动配置Webpack的规则。还有一些场景，比如需要热更新或动态加载模块时，生产环境构建可能不适用，这时候你得考虑用开发环境构建或者结合其他工具如Angular Universal。

六 替代方案或进阶技巧
如果你需要更细粒度的优化，可以考虑用Webpack的配置文件覆盖Angular CLI的默认设置。例如，在 `angular.json` 的构建配置中，添加 `"options": {"optimization": true, "outputHashing": "media", "sourceMap": false, "extractCss": true, "namedChunks": true, "aot": true}`，这样就能控制是否启用优化、是否提取CSS、是否生成命名的chunks。另外，你还可以用 `ng-packagr` 来打包自定义Angular库，它支持更复杂的打包策略，比如按需加载、tree-shaking和代码分割。对于SSR项目，搭配Angular Universal的 `ng build --prod --aot` 命令，不仅能优化客户端打包，还能优化服务端渲染的性能。还有，你可以在 `tsconfig.json` 中调整 `importHelpers` 和 `target` 参数，让TypeScript编译更快，从而提升构建效率。

七 构建缓存与增量构建
别以为构建优化就是改个参数，实际中你还可以利用Webpack的缓存机制，让构建更快。例如，在 `angular.json` 中启用 `"buildOptimizer": true`，它会优化代码并缓存结果，大幅提升构建速度。此外，Angular CLI的 `--incremental` 参数能开启增量构建，它会记住上次构建的输出，只重新编译发生变化的部分。这在大型项目中非常有用，因为每次构建时间都能减少一半以上。不过，这个参数在某些情况下会失效，比如你修改了模块结构或者更新了第三方库。这时候，你需要手动清除缓存，或者重新生成构建依赖图。

八 懒加载模块的配置细节
懒加载模块是Angular构建优化的关键，它能将非首屏的代码拆分成独立文件。配置懒加载模块需要你在 `app.module.ts` 中使用 `RouterModule.forRoot()`，并指定 `loadChildren` 函数。例如，你可以这样写：`loadChildren: () => import('./lazy-module/lazy-module.module').then(m => m.LazyModuleModule)`。这样，Angular会在运行时动态加载模块，而不是一开始就打包进去。不过，懒加载模块并不是万能，它依赖于路由配置，如果你的模块结构不合理，可能导致加载失败。此外，懒加载模块的路径必须正确，否则构建会报错。你可以用 `ng generate module` 命令来生成模块，这样能确保路径和结构符合Angular的要求。

九 代码分割与分包策略
代码分割是通过Webpack的splitChunks机制来实现的，它会把公共依赖和模块拆分成不同的文件。默认情况下，Angular CLI会使用这个机制，但你可以通过配置 `splitChunks` 来微调。例如，在 `angular.json` 的构建配置中，添加 `"splitChunks": {"chunks": "all", "cacheGroups": { "vendors": { "test": false, "priority": 10 }, "commons": { "test": true, "priority": 5 } }}`。这样，第三方库会被单独打包，而公共代码也会被提取出来。不过，你得注意splitChunks的配置会影响最终的文件数量，过多的分包可能导致HTTP请求次数增加，反而影响性能。所以，要根据项目实际情况调整配置，比如控制 `minSize` 和 `maxSize` 参数，避免生成太多小文件。

十 优化第三方库加载方式
第三方库的加载方式直接影响构建体积和性能。例如，对于Lodash，你可以用 `lodash-es` 替代 `lodash`，因为前者支持tree-shaking，而后者引入的是整个库。同样的，对于RxJS，你也可以使用 `rxjs` 的按需加载方式，而不是引入整个库。如果你在项目中使用了 `@angular/core` 或 `@angular/common`，那要确保是否真的需要所有功能。比如，`@angular/core` 的某些模块可能在你的项目中用不到，这时候你可以手动删除或使用按需加载方式。此外，使用 `npm install` 的 `--save-exact` 参数可以确保依赖版本一致，避免不必要的重复打包。

十一 使用Angular的Build Optimizer
Angular CLI 自带 Build Optimizer，它会在构建时对代码进行进一步优化，比如压缩、合并和删除无用代码。要开启它，只需要在 `angular.json` 的构建配置中设置 `"buildOptimizer": true`。这个优化器能减少打包体积，并提升代码执行效率。不过，它只适用于生产环境构建，开发环境不需要开启。另外，Build Optimizer对某些动态导入或第三方库的支持有限，这时候你可能需要手动配置Webpack的规则来替代。比如，对于某些需要动态加载的第三方库，你可以用 `require.ensure` 或 `import()` 来实现，这样Build Optimizer就能正确识别并优化。

十二 构建环境与打包策略的差异
开发环境和生产环境的构建策略完全不同。开发环境通常不会开启AOT，也不进行tree-shaking，这能让你快速修改代码并热更新。而生产环境则会开启所有优化，包括AOT、tree-shaking、代码分割和资源哈希。比如，你可以在 `angular.json` 中为不同环境配置不同的构建参数。例如，生产环境的 `optimization` 字段为 `true`，而开发环境为 `false`。你还可以用 `--configuration=production` 或 `--configuration=development` 来切换构建配置。不过，如果你在开发环境中用了AOT编译，那可能会影响调试体验，因为AOT会把组件信息编译成静态结构，难以跟踪。

十三 多环境打包与构建配置
Angular CLI 支持多环境打包，你可以在 `angular.json` 中配置多个构建配置，比如开发、测试、生产。每个配置都有不同的参数，比如是否开启AOT、是否进行代码分割、是否启用tree-shaking。例如，开发环境的配置可能是这样的：`"configuration": { "dev": { "optimization": false, "outputHashing": "none", "sourceMap": true } }`，而生产环境则是：`"configuration": { "prod": { "optimization": true, "outputHashing": "media", "sourceMap": false } }`。多环境打包能让你根据部署目标选择不同的优化策略，比如在测试环境开启source map，方便调试。但配置多了，也容易出错，所以建议保持配置简单，避免不必要的参数。

十四 构建输出目录的管理
构建输出目录通常在 `dist/your-project`，你可以自定义输出目录，比如在 `angular.json` 的构建配置中添加 `"outputPath": "dist/my-app"`。不过，输出目录的结构也很重要，比如 `main.js` 是主文件，`polyfills.js` 是polyfill文件，`styles.css` 是全局样式文件。你还可以用 `--output-hashing=media` 来优化文件名，让缓存更高效。另外，如果你用的是Angular Universal，输出目录会包含服务端和客户端两个部分，比如 `dist/my-app/client` 和 `dist/my-app/server`。这时候，你得确保服务器端构建和客户端构建的配置一致，否则可能会出现资源加载错误。

十五 依赖版本与构建性能的关系
依赖版本直接影响构建性能和体积。比如，使用较新的Angular版本通常会有更好的构建优化策略，而旧版本可能不支持某些高级特性。你可以用 `npm install` 的 `--save-exact` 参数确保依赖版本一致，避免构建时因版本差异导致的错误。同时，某些第三方库在新版本中已经优化了打包方式，比如 `@angular/material` 在Angular 17之后对tree-shaking的支持更好。如果你发现构建时间变慢，可以检查依赖版本是否过时，是否需要升级。不过，升级依赖可能会带来兼容性问题，比如模块路径变化或API调整，这时候你需要做代码兼容性测试，确保构建后的代码能正常运行。