Webpack 作为前端构建工具，最核心的职责是把分散的模块打包成可运行的产物。但在实际项目中，这份产物可能要跑在浏览器里，也可能要跑在 Node.js 服务端，甚至要塞进 Electron 桌面应用。决定这些差异的关键配置之一就是 target。很多人在配置 Webpack 时只改入口和输出，却忽略了 target，结果导致打包出的代码在目标环境频繁报错或体积异常。
target 的底层原理与默认行为
Webpack 在编译阶段会依据 target 的值来判断「目标运行时」具备哪些全局对象和模块能力。例如浏览器环境有 window、document，而 Node 环境有 require、__dirname。当 target 设为 web 时，Webpack 会认为代码最终由浏览器执行，于是把 process 等 Node 变量视为需要 polyfill 的外部依赖；当设为 node 时，它则直接保留 require 调用，不额外注入浏览器兼容层。
如果不显式配置 target，Webpack 5 的默认值是 web。这意味着即使你其实在写一个纯 Node 工具库，只要没改 target，打包结果也会包含大量针对浏览器的兼容代码，比如模拟 fetch 的垫片。这种错位不仅让包体变大，还可能因引用了不存在的浏览器全局而崩溃。理解 target 的本质，是正确打包的第一步。
从实现上看，target 会影响 Webpack 内部的 output.libraryTarget 默认值、NodeSourcePlugin 的注入逻辑以及 externals 的预设。比如 target 为 node 时，内置的 fs、path 等核心模块会被自动视为外部依赖，不参与打包，而是保留原生的 require('fs') 语句。这种机制让服务端代码能直接复用运行环境提供的能力。
常见 target 取值及适用场景对比
Webpack 官方提供了多个 target 预设，最常用的是 web、node、electron-main、electron-renderer 以及 async-node。它们分别面向浏览器、Node 主进程、Electron 主进程等不同运行时。选错值会让代码在目标平台无法启动。
以 web 和 node 为例，下面两段配置产生的产物结构完全不同。web 目标会把模块打包成立即执行函数，并注入 __webpack_require__ 的浏览器实现；node 目标则输出为 CommonJS 格式，且原生模块外置。我们可以用一个简单的配置对比来看差异：
// webpack.node.config.js
module.exports = {
target: 'node',
entry: './src/server.js',
output: {
filename: 'server.bundle.js',
path: __dirname + '/dist'
}
};
// webpack.web.config.js
module.exports = {
target: 'web',
entry: './src/client.js',
output: {
filename: 'client.bundle.js',
path: __dirname + '/dist'
}
};
在上面的 Node 配置中，由于 target 是 node，Webpack 不会去打包 express 以外的内置模块，反而会在产物里直接写 require('http')。而 web 配置下，如果代码里误用了 require('http')，Webpack 会尝试去 node_modules 找这个模块并打包，浏览器自然无法识别。这就是 target 决定依赖解析边界的典型表现。
还有一个容易忽视的点：electron-main 与 node 很像，但 Electron 主进程同时拥有 Node 和浏览器部分 API，因此 target 为 electron-main 时，Webpack 会保留 Node 能力，同时不把 Electron 自身当作外部依赖，方便直接调用 electron 模块。下表列出三者区别：
| target 值 | 运行位置 | 内置模块处理 | 全局对象 |
|---|---|---|---|
| web | 浏览器 | 尝试打包或 polyfill | window、document |
| node | Node 服务 | 视为外部依赖 | process、__dirname |
| electron-main | Electron 主进程 | 视为外部依赖 | process、electron 可用 |
多环境项目的 target 组合与进阶技巧
在大型仓库里，我们常需要同时构建浏览器包和 Node 包。此时不能为整个项目设单一 target，而应通过多配置文件或函数式配置返回不同 target。Webpack 支持 module.exports 为一个返回配置的函数，依据环境变量切换 target，这样就能在一次命令中并行产出多端产物。
另外，target 也支持传入对象形式做精细控制，比如 target: { node: '14', babel: true } 表示以 Node 14 为基线并启用 Babel 转换。这种写法在需要兼容特定 Node 版本的服务端渲染项目中非常实用。它比单纯字符串 node 多了语义版本约束，让 Webpack 更准确地决定哪些语法可以不转译。
如果你在写类库且希望用户自行决定运行环境，可以把 target 设为 web 同时配合 output.library 与 externals 把框架置为外部，避免重复打包 React 等大型库。但若是全栈同构应用，建议将客户端、服务端分别用不同 target 构建，并用 webpack-merge 复用基础配置。下面展示一个函数式配置的例子：
// webpack.config.js
module.exports = (env, argv) => {
const isNode = argv.target === 'node';
return {
target: isNode ? 'node' : 'web',
entry: isNode ? './src/server.js' : './src/client.js',
output: {
filename: isNode ? 'server.js' : 'client.js',
path: __dirname + '/dist'
},
externals: isNode
? { 'fs': 'commonjs fs', 'path': 'commonjs path' }
: {}
};
};
通过上述方式，执行 webpack --env --target=node 即可得到正确的服务端包。注意在 Node target 下手动声明 externals 有时更稳妥，因为某些第三方模块虽跑在 Node 但仍被 Webpack 误判为需要打包。掌握好 target 与环境变量的配合，就能让同一套源码适应任意部署场景，不再受运行时报错的困扰。