我在 Angular 文档中阅读了以下内容：
--供应商块
生成仅包含供应商库的单独捆绑包。此选项只能用于开发。
但是没有详细说明为什么此选项只能用于开发。我在其他地方读到，他们建议分离供应商块，这样当我们发布新版本的应用程序时，客户端就不需要再次下载它（因为主块发生了变化，但供应商块不一定会改变） ).
为什么 Angular 的文档建议仅在开发中使用它？
简单的答案是，如果您不强制将供应商文件拆分为单独的chuck，则树形抖动和其他构建优化通常会导致整体包大小更小。
总的来说，Angular 团队的建议在大多数情况下可能是正确的。
来自有关构建优化的当前文档：
如果您尝试弄清楚是否应该在应用程序中启用供应商块，请确保在比较大小时查看磁盘上的大小以及传输的大小（假设您正在使用某种形式的服务器压缩）像 gzip 或类似的。磁盘上的大小差异可能很小，但由于压缩的工作方式，压缩后的大小差异可能很大。 在实践中，您可能会发现您的应用程序的大小差异并不大。优化
构建系统包含旨在提高性能（对于开发构建）或工件大小（对于生产构建）的优化。这些通常是相互排斥的，因此我们不能默认总是使用它们。
开发优化
开发优化侧重于减少重建时间...
由于字符串连接和源映射操作的成本，捆绑代码所需的计算随着其总大小的增加而增长。最初加载的第三方依赖项被分割成一个名为vendor的同步加载块。将不经常更改的供应商代码与经常更改的源代码分开，从而有助于更快地重建。
生产优化
Angular CLI 专注于启用 tree-shaking（删除未使用的模块）和死代码消除（删除未使用的模块代码）。由于网络效应，这两个类别具有减少大小的巨大潜力：删除代码可能会导致更多代码被删除。 ... 这种优化策略的一个重大缺陷是使用代码分割。使用代码分割是可取的，以便通过延迟初始加载中不需要的代码来加速 Web 应用程序的加载。但由于代码分割必然要使用模块加载，因此它与基于 Terser 的优化不一致。
如果大小是一个洗涤，那么决定就是你是否经常更新供应商/第三方模块。如果这样做，那么拆分出单独的供应商块文件也没有太大的好处。无论是 2 个文件还是 1 个文件，在应用程序启动之前都需要下载相同数量的代码（并行下载可能会节省很少的费用 - 为您的应用程序进行测试，但同样，可能微不足道）。
如果您不经常更改供应商代码，并且您验证文件大小差异可以忽略不计，并且文件哈希通常在重建时保持不变（优化可能会导致文件内容和哈希发生更改，即使您的供应商没有更改），那么这可能会给您的用户带来一点好处，因为当您发布新的应用程序版本时，只需要下载核心应用程序代码，而供应商块如果与之前缓存的版本相比没有更改，则可以继续使用.
来自
旧版本的 Angular 文档的更多信息（大部分是准确的，但请注意，自编写本文以来，优化方法有所不同）
--build-optimizer 和 --vendor-chunk 使用构建优化器时，默认情况下将禁用供应商块。您可以使用 --vendor-chunk=true 覆盖它。
如果没有单独的供应商块，则使用构建优化器的总包大小会更小，因为将供应商代码与应用程序代码放在同一块中使得可以......删除更多未使用的代码。