ng build 是 Angular 项目中用于构建应用的命令。当这个命令执行时，Angular CLI 使用 Webpack 来打包应用程序的代码，并最终输出多种类型的文件。Names 列是表格中用来描述每个打包生成的文件在应用程序中的角色和用途的一列。

Names 列中的内容并不是随意生成的，而是根据 Angular 项目中的不同模块、文件的命名、以及项目中使用的构建配置来确定的。具体而言，Names 列的内容来源包括以下几个方面：

1. 入口文件（Entry Points）
   在 Angular 项目中，存在多个入口文件，这些入口文件是 Angular 项目运行的核心所在。例如，默认情况下，Angular 使用 main.ts 作为应用的主入口文件。这个文件定义了应用启动的方式，并加载应用的根模块。

   在构建过程中，Webpack 会将 main.ts 所引用的所有代码及其依赖整合到一个单独的 JavaScript 文件中，这个文件通常命名为 main.js，Names 列中看到的 main 就是从这里提取出来的。因此，Names 列中的 main 代表的是应用的主入口文件对应的代码块，包含了应用的核心逻辑。

   真实案例可以举一个典型的企业管理系统为例：假设有一个 ERP 系统，main.ts 文件包含了系统启动时需要加载的核心模块，例如用户认证模块、数据管理模块等。这些模块会通过 AppModule 进行导入和管理。在执行 ng build 时，这些模块及其依赖会被打包到 main.js 中。因此，Names 列中的 main 对应的就是整个应用的主要业务逻辑代码块。

2. 第三方依赖（Vendor Chunk）
   在 Angular 应用中，通常会依赖很多第三方库和工具，例如 Angular 本身、RxJS、Bootstrap 等。这些第三方依赖通常不会频繁更新，因此在构建时，Webpack 会将它们单独打包到一个名为 vendor.js 的文件中，而 Names 列中则会显示为 vendor。

   这样做的好处是能够更好地利用浏览器的缓存机制。如果用户第二次访问应用时，第三方库没有变化，那么浏览器就可以直接使用缓存的 vendor.js，从而显著提升加载速度。

   例如，一个电子商务平台可能会使用一些第三方库来处理支付、用户身份验证和数据可视化。在这种情况下，诸如 Stripe.js（支付相关库）和 D3.js（数据可视化库）等第三方库就会被打包到 vendor.js 中。当用户访问这个电子商务平台时，如果这些库没有变化，浏览器就可以利用缓存，从而减少加载时间。

3. 运行时代码（Runtime Chunk）
   runtime.js 是一个包含 Webpack 运行时代码的文件，Names 列中会显示为 runtime。它用于管理应用中不同模块之间的依赖，并确保按需加载模块时能够正确地加载和初始化。

   运行时代码在应用程序启动时发挥着重要作用，它负责追踪哪些模块已经加载，哪些还未加载。例如，假设应用中有一些懒加载模块（即用户访问某个特定路由时才加载的模块），runtime.js 会负责在用户导航到该路由时动态加载相应的代码块。

   举个例子，假设有一个新闻门户网站，其中包含多个独立的新闻模块，比如体育、科技、娱乐等。在用户进入首页时，只会加载基本内容，而当用户点击进入“体育新闻”页面时，runtime.js 会协助加载相应的模块代码，确保页面的渲染能够顺利完成。

4. 多入口点（Lazy Loading Modules）
   在 Angular 中，开发者可以使用懒加载来提升应用的性能，尤其是在大型应用中。懒加载意味着某些模块只有在用户实际访问时才会被加载，而不是在应用启动时就全部加载。Webpack 在打包这些懒加载模块时会为每个模块生成一个单独的 chunk，这些 chunk 的名字通常和模块的名字相关联。

   例如，在 Angular 路由配置中，使用 loadChildren 来配置懒加载模块：

   {
     path: 'admin',
     loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule)
   }
   

   在构建输出中，admin 模块会被单独打包为一个 chunk，并且在 Names 列中会显示为 admin。这样，当用户访问 /admin 路径时，应用就会动态加载 admin 模块的代码，提高了应用的初始加载速度。

   现实中的一个应用场景可以是一个在线教育平台，假设平台有多个独立的模块，例如课程管理模块、学生管理模块、考试模块等。在用户首次登录时，只加载基本的用户信息模块，而当用户点击进入“课程管理”页面时，admin.js（代表课程管理模块）才会被动态加载，Names 列中对应的名称则为 admin，表明这个模块对应管理功能。

5. 样式和 Polyfills
   构建输出中还可能包含一些与样式和浏览器兼容性相关的代码块，通常这些代码块会有以下名称：

   • styles：包含应用程序的全局样式表。在 Angular 项目中，全局样式文件（如 styles.css 或 styles.scss）会被单独打包到一个 JavaScript 文件中。Names 列中出现的 styles 代表的就是这个文件，它主要负责在运行时应用全局样式。

   • polyfills：包含垫片（polyfills）代码，用于填补不同浏览器之间的功能差异，使得应用在所有主流浏览器上表现一致。例如，某些较老的浏览器可能不支持 ES6 的某些特性（如 Promise），那么这些功能就会由 polyfills.js 来模拟。Names 列中的 polyfills 就是从项目的 polyfills 配置中提取出来的。

   在现实世界中，考虑一个需要支持广泛浏览器版本的项目，例如一个政府网站，必须确保在某些较旧版本的浏览器上也能够正常运行。在构建过程中，polyfills.js 文件会包含所有需要的垫片代码，以确保应用可以在这些旧版浏览器上无障碍运行。

6. 与文件名相关的配置
   Angular 项目中的构建配置文件可以对生成的 chunk 名称进行配置。默认情况下，Angular 会根据文件的用途自动命名这些 chunk，例如 main.js、vendor.js 等，但我们也可以在 angular.json 配置文件中对它们的命名进行自定义。例如：

   "outputHashing": "all"
   

   上述配置可以对生成的 chunk 文件名添加哈希值，以确保在部署时，如果文件内容有改动，浏览器能够识别并加载新的文件，而不是使用缓存中的旧文件。这样做的好处在于减少缓存问题的发生。

   对于电子商务网站来说，这种配置非常有用。例如，网站的产品页面模块可能会频繁更新，输出哈希值可以确保用户始终看到最新版本的产品信息，而不是被浏览器缓存误导而看到旧的内容。

总结：Names 列信息来源的综合理解

综上所述，ng build 输出表格中 Names 列的内容是从项目中的不同模块、文件、以及构建配置中提取出来的。这一列的主要目的是帮助开发者快速识别每个生成文件的角色和用途，从而更好地理解应用的构建结构。

具体来说，Names 列可以帮助我们识别以下几种代码块：

• 主入口文件（main）：对应应用的核心业务逻辑，是从 main.ts 提取出来的。
• 第三方库依赖（vendor）：包含所有第三方依赖库，通常在项目中使用多个库时会生成这个代码块。
• 运行时代码（runtime）：管理模块之间的依赖关系，确保按需加载模块时能够正常运行。
• 懒加载模块：从路由配置中的懒加载模块中提取，例如 admin。
• 样式（styles）和垫片（polyfills）：用于确保应用在所有主流浏览器中的一致性。

通过分析这些代码块的来源，开发者可以清晰地了解应用的架构，从而更有效地进行性能优化。例如，利用懒加载减少初始加载体积，通过哈希输出确保内容更新的及时性，以及对第三方依赖进行拆分来提升应用的缓存效果。