Webpack 5 发布已经有一段时间了，但很多项目依然沿用旧版的 worker-loader 来处理 Web Worker。其实只要打开 experiments.workers，就能用浏览器原生支持的 Worker 语法，省去额外依赖和配置。这个配置项背后是 Webpack 对 Worker 构造函数的特殊处理，理解它的工作方式能帮你少踩不少坑。
为什么需要 experiments.workers
过去在 Webpack 里使用 Web Worker 并不算直观。常见的做法是安装 worker-loader，然后在代码里写 import Worker from 'worker-loader!./worker.js'，或者配置 rules 用 test 匹配 Worker 文件。这种方式虽然能用，但有几个明显问题：一是语法和浏览器标准不一致，代码可移植性差；二是增加了对第三方 loader 的依赖，升级时容易出现兼容性问题；三是在 TypeScript 项目中还需要额外的类型声明，否则 import 会报错。
Webpack 5 引入的 experiments.workers 配置项正是为了解决这些痛点。它让 Webpack 直接支持浏览器原生的 Worker 构造语法，即 new Worker(new URL('./worker.js', import.meta.url))。这种写法不需要任何 loader，而且在 Vite、Rollup 等现代打包工具中也是通用的。开启该配置后，Webpack 会静态分析 Worker 构造函数的第一个参数，将其作为入口文件单独打包，并自动处理文件哈希、公共路径和依赖分析。
从实现角度看，Webpack 内部会把 Worker 依赖视为一种特殊的模块类型。当 experiments.workers 为 true 时，构建过程会识别 new URL(..., import.meta.url) 这一模式，并生成一个独立的 chunk。运行时通过 Blob URL 或 data URI 加载 Worker 脚本，从而保证 Worker 文件的跨域隔离和缓存策略与主线程一致。
开启配置并编写原生 Worker 代码
首先在 webpack.config.js 中开启实验特性。配置很简单，只需在 experiments 对象中加入 workers: true。示例配置如下：
module.exports = {
experiments: {
workers: true
},
// 其他配置项省略
};
接下来编写 Worker 文件。假设文件名为 heavy-task.worker.js，内容如下：
// heavy-task.worker.js
self.onmessage = function(e) {
const { data } = e;
let sum = 0;
for (let i = 0; i < data; i++) {
sum += i;
}
self.postMessage(sum);
};
在主线程中，使用标准语法创建 Worker 实例。需要注意，new URL('./heavy-task.worker.js', import.meta.url) 返回的是一个 URL 对象，Worker 构造函数会解析该 URL 并加载对应脚本。示例代码：
// main.js
const worker = new Worker(new URL('./heavy-task.worker.js', import.meta.url));
worker.onmessage = function(e) {
console.log('计算结果：', e.data);
};
worker.postMessage(1000000);
运行构建后，Webpack 会生成一个独立的 chunk 文件，主线程中不会包含 Worker 的代码。浏览器会在运行时通过 Blob 或 URL 加载这个 chunk。整个过程不需要修改 Worker 文件内部的 import 语法，Worker 内也可以使用 ES module import 来引入其他模块，Webpack 会一并处理依赖。
另一个优点是，experiments.workers 还支持 sharedWorker 和 inline worker。前者通过 new SharedWorker(new URL(...)) 使用共享线程，后者则可以在 Worker 构造函数中传入 type: 'module' 选项来实现 ES module Worker。不过这些高级用法需要浏览器支持，建议在使用前做好兼容性检测。
与 worker-loader 的对比及迁移建议
worker-loader 的典型用法是 import Worker from 'worker-loader!./worker.js'，或者通过 module.rules 配置 test: /\.worker\.js$/ 并指定 loader。这种方式在 Webpack 5 中依然可用，但官方已经将其列为 legacy 方案，推荐使用原生支持。两种方案的核心差异在于：worker-loader 在编译期生成一个包装类，通过 import 返回一个 Worker 构造函数；而 experiments.workers 直接解析原生 Worker 构造语法，不改变代码语义。
迁移时，建议按以下步骤操作：第一步，将 worker-loader 相关依赖和 rules 移除；第二步，在 experiments 中加入 workers: true；第三步，把主线程中的 import Worker from './worker.js' 替换为 const worker = new Worker(new URL('./worker.js', import.meta.url))；第四步，确保 Worker 文件内部没有使用只有 worker-loader 才能提供的特殊导入。如果项目中使用了 TypeScript，还需要在 tsconfig 中为 Worker 文件添加类型声明，或者使用 // @ts-ignore 临时跳过检查。
需要注意的是，某些旧项目可能依赖 worker-loader 的 inline 模式或自定义 publicPath。原生方案无法直接复刻这些行为，例如 inline worker 可以通过 new Worker(URL.createObjectURL(new Blob([code]))) 手动实现，但代码复杂度和可维护性会下降。因此迁移前要先评估这些特殊用法是否必需。
常见问题与调试技巧
第一个常见问题是 Worker 文件路径解析失败。报错通常类似于 Failed to construct 'Worker': Script at '...' cannot be accessed from origin '...'。这往往是因为 new URL('./worker.js', import.meta.url) 中的相对路径写错，或者 Worker 文件不在模块上下文中。请确认 Worker 文件的扩展名与配置中的 asset 规则一致，并且没有被其他 loader 错误处理。
第二个问题是开发模式下的热更新。启用 experiments.workers 后，Worker 文件的变化有时不会触发页面自动刷新，或者刷新后 Worker 代码没有更新。这是因为 Webpack 将 Worker 作为独立 chunk 缓存，HMR 不会主动推送更新。临时解决办法是手动刷新页面，或者在 devServer 配置中关闭 hot，改用 liveReload。长期方案则需要等待 Webpack 团队完善 HMR 对 Worker 的支持。
第三个问题是跨域限制。如果 Worker 文件来自 CDN 或不同子域，浏览器会阻止其加载。为了解决这个问题，可以配置 output.publicPath 为同域地址，或者使用 devServer 的 headers 选项添加 CORS 头。另外，如果项目中使用了 splitChunks 拆分公共依赖，Worker 内引入的模块也可能被抽离到主线程 chunk 中，导致运行时错误。此时需要调整 splitChunks.cacheGroups 配置，避免 Worker 依赖被误合并。
还有一个调试相关的技巧：在浏览器开发者工具中查看 Sources 面板时，原生 Worker 可能显示为 blob: 开头的地址，不易定位源码。可以开启 webpack 的 devtool: 'source-map' 选项，这样 Worker 内的错误堆栈会映射回原始文件路径，排查问题会轻松许多。
