Webpack 的按需加载并非直接把脚本写死到页面，而是通过在全局环境暴露一个数组变量来完成 chunk 的注册和加载协调。当同一个页面同时运行多个由 Webpack 构建的应用或微前端模块时，如果两个运行时使用了相同的全局变量名，后加载的运行时就会覆盖前者的数组，导致动态 import 报错、chunk 重复执行或者模块缓存错乱。output.chunkLoadingGlobal 配置项正是为了解决这个冲突而存在，它允许开发者给每个构建产物指定一个独一无二的全局变量名，从而把不同应用的加载通道隔离。

Webpack 按需加载为什么依赖全局数组

Webpack 处理动态 import 时，不会把模块代码全部打包进一个文件，而是拆分成 chunk。浏览器加载这些 chunk 使用的是 JSONP 思路：运行时先准备一个全局数组变量，并重写它的 push 方法；带 chunk 的文件被 script 标签加载后，会立即执行一段代码，把当前 chunk 包含的模块定义通过 push 方法传给运行时。运行时收到后，再解析模块 ID 和依赖关系，完成模块注册与执行。这个过程绕开了 ES Module 的静态限制，是 Webpack 在浏览器端最高效的按需加载方案之一。

全局数组的默认名称并非随机生成。Webpack 会根据 output.library 或者包名、入口等信息推导出一个字符串，多数情况下类似 webpackChunk_项目名。如果开发者没有显式配置，两个独立的构建产物很可能生成相同的名字。例如一个主应用和一个子应用都是基于同一个脚手架创建，项目名都叫 my-app，那么它们都会尝试挂载 window.webpackChunk_my_app。第二个运行时执行时，会覆盖第一个运行时设置的 push 方法，导致第一个应用后续的异步 chunk 无法被正确接收。

这种冲突在微前端和大型单页中尤其常见。因为多个团队可能分别构建自己的应用，再被同一个壳工程整合到页面里。冲突的表现往往不稳定：有时只是某个动态路由加载失败，有时是 chunk 依赖版本错乱，有时甚至不报错但模块执行顺序出错。定位起来很费时。理解全局数组的机制后，解决思路就很明确：给每个运行时一个独立的全局变量名。

// 简化后的 webpack runtime 核心逻辑
var globalName = "webpackChunk_my_app";
var chunkLoadingGlobal = self[globalName] = self[globalName] || [];
chunkLoadingGlobal.push = function (chunkData) {
  // 遍历 chunkData 中的模块定义并缓存到 modules 对象
  for (var moduleId in chunkData[1]) {
    modules[moduleId] = chunkData[1][moduleId];
  }
};

用 output.chunkLoadingGlobal 隔离不同应用

Webpack 暴露给开发者的配置项 output.chunkLoadingGlobal 可以直接覆盖默认的全局数组名。它的用法很简单，在 webpack.config.js 的 output 字段下指定一个字符串即可。配置后，运行时创建的数组名称会变成自定义值，所有异步 chunk 脚本也会在加载后向这个自定义数组推送模块定义。只要不同应用使用不同的名称，冲突就不会发生。

module.exports = {
  output: {
    chunkLoadingGlobal: 'appAdminChunkGlobal',
    // 也可以使用环境变量或包名动态生成
    // chunkLoadingGlobal: process.env.APP_NAME + 'ChunkGlobal',
  },
  // 其他配置
};

需要注意的是，chunkLoadingGlobal 只在浏览器环境且使用 JSONP 方式加载 chunk 时有效。如果你的 target 设置成 node 或者使用 importScripts 加载，Webpack 不会使用这个全局变量。通常单页应用的默认 target 是 web，无需额外设置。如果项目里同时存在多个 target，比如 SSR 场景下的 client 和 server 构建，只需要在 client 配置中设置，server 端不必处理。

配置这个字段时，建议使用带业务含义的前缀，而不是简单的 webpackChunk。比如 appAdminChunkGlobal、appUserChunkGlobal，这样在浏览器控制台里排查时也更容易识别。同时要避免使用可能的保留关键字或已经存在的全局变量，例如不要直接使用 Array 或 JSON 等内置对象名，否则可能干扰原生对象。

微前端与模块联邦场景下的注意事项

在微前端架构中，多个子应用通常由不同团队独立构建，它们之间的全局变量冲突非常常见。除了 chunkLoadingGlobal，Webpack 5 还提供了 output.uniqueName 配置，用于避免多个构建之间的内部全局变量冲突。uniqueName 会影响全局数组的默认命名、模块联邦的共享范围以及一些内部运行时标记。当设置了 uniqueName 后，即使不显式设置 chunkLoadingGlobal，Webpack 也会根据 uniqueName 生成唯一的全局变量名。两者的关系可以理解为：uniqueName 是更高层面的隔离策略，chunkLoadingGlobal 是更细粒度的加载通道控制。

module.exports = {
  output: {
    uniqueName: 'admin-app',
    chunkLoadingGlobal: 'adminAppChunkGlobal',
  },
};

如果项目使用了 Module Federation，仅仅设置 chunkLoadingGlobal 可能还不够。模块联邦本身需要共享一个全局的 chunk 加载机制，远端模块和宿主应用之间的 chunk 加载协调依赖一致的全局数组。此时建议宿主的 remote 容器和各个 remote 应用都设置相同的 chunkLoadingGlobal，或者通过 uniqueName 保证一致性。否则远端模块动态 import 的代码可能被扔进一个无人监听的数组，导致加载超时或模块未定义。

另一个容易忽略的点是：当多个 Webpack 构建产物来自不同的 Webpack 版本时，运行时内部对全局数组的处理方式可能略有差异。为了减少兼容性问题，尽量保持各应用使用相同大版本，并且在配置文件里显式设置 chunkLoadingGlobal，避免依赖默认的推导规则。如果无法统一版本，至少要通过设置不同 chunkLoadingGlobal 来减少冲突。

如何验证和排查全局变量冲突

验证配置是否生效最简单的方法是在浏览器控制台查看全局变量的实际值。打开页面后，输入 Object.keys(window).filter(function (key) { return key.indexOf('webpackChunk') === 0 || key.indexOf('appAdminChunkGlobal') === 0; }); 这段代码会列出当前页面中所有由 Webpack 创建的全局数组。执行后如果只看到自己应用配置的名称，说明隔离已经生效；如果还看到其他名称，则需要继续排查哪些构建产物没有设置 chunkLoadingGlobal。

// 在浏览器控制台运行，查看与 webpack chunk 相关的全局变量
Object.keys(window).filter(function (key) {
  return key.startsWith('webpackChunk') || key.endsWith('ChunkGlobal');
}).forEach(function (key) {
  console.log(key, window[key]);
});

如果出现类似 Loading chunk failed、Cannot read properties of undefined (reading 'call')、ChunkLoadError 等错误，可以优先检查是不是页面中同时存在多个 Webpack 构建产物。通过开发者工具的全局搜索，找到所有打包文件里包含 webpackChunk 前缀的位置，确认哪些 chunk 在加载时使用了哪些全局名称。很多时候只需要给冲突的那个应用加上一个唯一的 chunkLoadingGlobal，问题就能解决。

还有一类隐性冲突是：两个应用都使用了同一个 chunk 文件名，例如都配置了 output.filename: '[name].js' 且 chunk 名相同。即使全局数组名不同，浏览器缓存或 script 标签可能加载到了错误的文件。所以除了 chunkLoadingGlobal，还应该给每个应用设置独立的 output.path 或 publicPath，确保资源 URL 不同。排查时可以先清掉缓存和 service worker，再观察加载的 chunk 文件是否符合预期。