不少人在升级 Webpack 5 之后发现，同样的配置文件打出来的包和 Webpack 4 时代不太一样了：箭头函数可能被保留了，mainField 的默认值变了，某些运行时报错也莫名其妙多起来。这些变化的根源之一，就是 Webpack 5 对编译目标体系的一次彻底重构。官方在新版文档里用 Goal（目标）来描述这套体系，它决定了你的代码最终会被编译成什么形态、跑在哪个运行时上。这篇文章就来把 target 配置讲透。
target 到底控制了什么
简单来说，target 告诉 Webpack 两件事：第一，产物运行在哪个环境（浏览器、Node、还是 Electron 的主进程与渲染进程）；第二，产物的语法层面需要兼容到什么程度（ES5、ES2015 还是 ES2020）。这两件事组合起来，就构成了 Webpack 5 里所说的 Goal。
在 Webpack 4 中，target 的取值基本就是一个字符串，比如 target: 'web' 或者 target: 'node'，环境的语法兼容性是隐含绑定的，你想细粒度控制并不容易。Webpack 5 把它拆成了两个维度，你可以写成 target: ['web', 'es2020'] 这样的数组形式，第一个元素描述运行环境，第二个元素描述 ES 版本。这种写法带来的直接好处是灵活：你可以在不牺牲环境判断的前提下，精确指定语法降级的目标。
target 会影响的行为远比想象中多。它会决定 chunk 的加载方式（浏览器端用 script 标签异步加载，Node 端用 require），会改变 package.json 中 browser 字段和 main 字段的优先级，还会影响 node 全局变量（如 process、__dirname）是否被 polyfill 或直接保留。理解了这一点，很多诡异的构建问题就能找到答案。
常用取值与组合写法详解
单独的字符串写法仍然是最常见的。web 表示面向浏览器，这是默认值；node 表示面向 Node.js，此时 Webpack 会按 CommonJS 方式加载 chunk；electron-main 和 electron-renderer 分别对应 Electron 的主进程和渲染进程；webworker 面向 Web Worker 环境。基础配置如下：
module.exports = {
target: 'node' // 产物运行在 Node.js 环境
};数组写法是 Webpack 5 的新能力，环境与 ES 版本可以自由组合：
module.exports = {
// 面向浏览器，语法兼容到 ES2020
target: ['web', 'es2020'],
// 面向 Node 16，产物保持 ES2020 语法
target: ['node16', 'es2020']
};值得注意的细节是：当你把 ES 版本设置为 es5 时，Webpack 会尽量避免在运行时代码中生成箭头函数和 const、let 声明；而设置为 es2020 或更高时，运行时会直接使用箭头函数。这解释了为什么有些老设备（比如某些智能电视内置浏览器）跑 Webpack 5 打包的现代库会白屏——不是你的业务代码没降级，而是 target 没设对，Webpack 自带的运行时胶水代码根本没做 ES5 兼容。
另外一个容易被忽略的行为是 browserslist 的自动推断。如果你的项目 package.json 里配置了 browserslist 字段，或者存在 .browserslistrc 文件，Webpack 5 会根据它自动推导出一个合适的 target。这本来是个贴心的功能，但如果你同时显式写了 target，显式配置优先，browserslist 会被忽略，两者混用时容易产生认知偏差，建议团队内约定只保留一种来源。
实战场景：Electron 与同构应用的配置方案
Electron 项目是 target 配置最容易踩坑的场景。因为主进程跑在 Node 上，渲染进程跑在 Chromium 里，两者的模块加载方式和全局变量完全不同，必须分开打包。实践中通常写两份配置，通过环境变量切换：
const commonConfig = {
mode: 'production',
output: {
path: path.resolve(__dirname, 'dist')
}
};
module.exports = (env) => {
if (env.target === 'main') {
return merge(commonConfig, {
target: 'electron-main',
entry: './src/main/index.js',
output: { filename: 'main.js' }
});
}
return merge(commonConfig, {
target: ['electron-renderer', 'es2020'],
entry: './src/renderer/index.jsx',
output: { filename: 'renderer.js' }
});
};渲染进程这里搭配了 es2020，因为 Electron 内置的 Chromium 版本较新，完全没有必要把运行时降级到 ES5，保留现代语法可以减小产物体积，也能提升 tree shaking 与作用域提升的效果。
同构应用（SSR）是另一个典型案例。服务端 bundle 应该用 ['node', 'es2020']，避免 Webpack 把 Node 内置模块错误地 polyfill；客户端 bundle 则用 ['web', 'es2020']。如果你用的是 webpack-node-externals 这类工具把 node_modules 排除掉，target 设成 node 还能确保 chunk 加载逻辑走 require 路径，不会在服务端触发浏览器专属的动态加载代码。
target 配置不当的典型症状与排查
第一个典型症状是报错 Uncaught SyntaxError: Unexpected token '=>' 或类似的语法错误。这几乎一定是 target 的 ES 版本设得太高，而运行环境太老。排查时先确认产物里是否含有箭头函数，再检查 target 与 browserslist 是否冲突。
第二个症状是 Node 端运行报 self is not defined 或 window is not defined。这通常说明 target 设成了默认的 web，Webpack 在运行时里引用了浏览器全局对象。把 target 改成 node 即可解决。
第三个症状比较隐蔽：某些依赖包引入后体积异常大。原因是 package.json 里的 browser 字段映射只有当 target 包含 web 时才会生效。如果 target 是 node，包会走 Node 版本的入口文件，体积差异可能达到数倍。反过来，在浏览器环境里误用 node 目标则可能把 Node 专属依赖打进去，直接导致运行时崩溃。
总结一下配置建议：明确写出数组形式让意图清晰，比如 ['web', 'es2020']；统一团队内 browserslist 与 target 的来源，避免两套口径；Electron 项目务必区分主进程与渲染进程的目标配置。把 Goal 体系理解到位，Webpack 5 的产物行为就基本不会有意外了。