Angular13.1.1项目打包体积3.5M是否正常？求优化建议

体积是否正常 #

首先明确：3.5M是未压缩的dist体积的话，属于Angular项目的中等水平；如果是gzip压缩后的大小，那确实偏大，需要重点优化。Angular项目的未压缩打包体积通常在2M-5M之间，取决于第三方依赖的数量和大小，所以你的情况不算异常，但仍有优化空间。

针对node_modules重复打包的优化方案 #

从webpack-bundle-analyzer的结果来看，多处包含node_modules模块大概率是重复打包或未做依赖抽离导致的，可按以下步骤优化：

• 排查重复依赖版本：用npm ls <package-name>命令检查核心依赖（比如rxjs、@angular/*系列库）是否存在多版本共存的情况，统一依赖版本能避免重复打包。
• 启用Angular内置依赖优化：在angular.json的build配置中，确保optimization开启，同时设置commonChunk: true，将多个组件共享的第三方模块抽成单独的common.jschunk，避免重复打包到各个业务chunk中。
• 强化树摇效果：确保tsconfig.json中compilerOptions.module设为es2020或更高版本，target设为es2015+；同时避免全量导入（比如import * as _ from 'lodash'），改用按需导入（import { debounce } from 'lodash-es'），让webpack能彻底摇掉未使用的代码。
• 替换大体积第三方库：如果项目中使用了moment.js、lodash这类体积较大的库，可替换为轻量替代方案（比如date-fns、lodash-es），或者使用组件库的按需加载（比如Angular Material、NG-ZORRO的按需引入）。
• 精细化懒加载：除了路由级懒加载，可尝试组件级懒加载——用import()动态导入非首屏组件，配合Angular 13+的独立组件特性，进一步拆分首屏打包体积。

补充优化点 #

• 确认压缩配置：务必在服务器端开启gzip或Brotli压缩，这是最有效的体积缩减手段——3.5M未压缩体积经gzip后通常能降到1M左右，直接降低用户下载耗时。
• 清理冗余代码：持续检查是否有未使用的组件、服务或导入语句，可借助Angular CLI的ng lint工具自动检测冗余代码。

内容的提问来源于stack exchange，提问作者Vince