Angular 14迁移至18（ESBuild）后初始Chunk数量激增的问题咨询

嗨，我来帮你捋捋这个问题——不少开发者从Webpack切换到ESBuild的时候都碰到过类似的chunk拆分变化，咱们逐个说清楚你的疑问：

1. 这是Angular 18搭配ESBuild的正常行为吗？ #

完全正常！这其实是ESBuild默认拆分策略的典型表现。之前Webpack打包初始模块时，倾向于合并成几个大bundle；但ESBuild的设计思路更侧重缓存命中率优化——它会把代码拆得更细，哪怕是初始加载的模块也不例外。这样一来，后续如果只有某个小模块更新，用户只需要重新下载那一个小chunk就行，不用动大文件。你提到总JS大小和之前差不多，也正好印证了这一点：只是同一份代码的拆分方式变了，并没有额外增加代码量。

2. 有没有办法减少或者控制初始chunk的数量？ #

当然有，你可以通过调整Angular的ESBuild配置来搞定：

• 按大小合并初始chunk：在angular.json的项目architect.build.options里，添加esbuild配置项，通过splitChunks规则来限制拆分粒度，比如强制把初始依赖合并到不超过指定大小的chunk里：

  "build": {
    "builder": "@angular-devkit/build-angular:application",
    "options": {
      // 你的其他原有配置...
      "esbuild": {
        "chunkNames": "[name]-[hash]",
        "splitChunks": {
          "initial": {
            "maxSize": "500kb", // 超过500kb才拆分新的chunk
            "minSize": "100kb"   // 小于100kb的模块直接合并到现有chunk
          }
        }
      }
    }
  }
  

• 先确认部署环境的HTTP版本：如果你的服务器支持HTTP/2，其实不用太担心多文件的问题——HTTP/2支持多路复用，能同时加载多个小文件，性能损失远没有HTTP/1.x那么严重，这也是ESBuild默认拆细的前提之一。

3. 能不能像之前用Webpack那样自定义chunk拆分策略？ #

ESBuild的自定义灵活性确实不如Webpack，但也不是完全没空间：

• 基础自定义可以直接在angular.json的esbuild.splitChunks里配置，比如指定哪些第三方库要合并到同一个chunk，或者按模块路径来分组；
• 如果需要更精细的控制，你可以在项目根目录创建esbuild.config.js，直接用ESBuild的API编写自定义拆分逻辑，然后在angular.json里指定这个配置文件的路径：

  "build": {
    "options": {
      // 其他配置...
      "esbuildConfig": "esbuild.config.js"
    }
  }
  

  比如在这个配置文件里，你可以针对特定依赖（比如RxJS、Angular Material）设置单独的chunk规则，或者根据模块的导入关系来合并chunk。

最后再提个小建议：如果你的项目里有大量共享的公共依赖，ESBuild默认会把它们拆成单独的chunk，要是你想减少文件数量，也可以通过配置强制把这些公共依赖合并到初始chunk里。

内容来源于stack exchange