Webpack为何取代Grunt：前端构建范式的代际跃迁

1. 项目概述：一场前端构建工具的代际更替实录

“Why WebPack is Eating Grunt’s Lunch”——这个标题不是夸张修辞，而是2014–2016年间真实发生在前端工程现场的静默革命。我亲身参与过三个大型企业级SPA项目的迁移：一个用Grunt+RequireJS构建的金融后台系统，一个基于Gulp+Browserify的电商中台，还有一个从零启动、直接选用Webpack 1.x的SaaS管理平台。三年后回看，前两者都完成了彻底重构，而第三个至今仍在同一套Webpack配置主干上迭代升级——不是因为“它没坏”，而是因为“它根本不需要大修”。Webpack吃掉Grunt的午餐，本质不是功能碾压，而是对前端开发范式演进的精准响应：当模块化从“可选方案”变成“基础设施”，当代码分割从“高级技巧”变成“默认行为”，当开发体验从“手动拼接”转向“开箱即用”，Grunt那套基于文件流（file-based）的、任务驱动（task-driven）的构建哲学，就天然失去了底层适配能力。

核心关键词——Webpack、Grunt、前端构建、模块打包、代码分割、HMR（热模块替换）——全部指向一个事实：这不是工具之争，而是工程思维的代差。Grunt擅长“把A文件压缩成B文件，再把C文件合并进D文件”，它像一位经验丰富的老裁缝，按图纸逐针缝制；Webpack则像一位建筑结构师，它不关心单块砖怎么烧，而是先定义楼层功能、承重逻辑、管线走向，再反向组织砖、梁、水泥的供应节奏。这种差异直接体现在日常开发中：Grunt用户常在grunt-contrib-uglify和grunt-contrib-cssmin之间反复调试路径通配符，而Webpack用户更多时间花在理解splitChunks策略如何影响首屏加载水线。本文不讲“Webpack比Grunt快多少”，而是带你拆解这场替代背后的四层不可逆动因：模块依赖图谱的自动发现机制、运行时模块系统的原生集成、开发期体验的范式重构、以及生态扩展模型的根本性升级。无论你今天用Vite还是Turbopack，理解这段历史，就是理解现代前端工程化的底层契约。

2. 构建范式的代际跃迁：从文件流水线到依赖图谱驱动

2.1 Grunt的“文件搬运工”逻辑与它的天花板

Grunt的核心抽象是任务（Task）和文件（File）。每个插件（如grunt-contrib-jshint）本质上是一个独立的CLI工具封装，Grunt本身只负责按配置顺序调用它们，并传递文件路径。看一个典型Gruntfile.js片段：

module.exports = function(grunt) { grunt.initConfig({ jshint: { files: ['src/**/*.js'], options: { globals: { jQuery: true } } }, concat: { dist: { src: ['src/lib/*.js', 'src/app/*.js'], dest: 'dist/bundle.js' } }, uglify: { dist: { files: { 'dist/bundle.min.js': ['dist/bundle.js'] } } } }); grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.loadNpmTasks('grunt-contrib-concat'); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt.registerTask('default', ['jshint', 'concat', 'uglify']); };

这段代码暴露了Grunt的三个结构性局限：

1. 路径强耦合：src/**/*.js、src/lib/*.js等通配符必须精确匹配物理文件结构。一旦团队约定“组件按功能目录组织”（如src/components/Button/），所有任务配置都要重写路径，且无法感知Button/index.js是否真的被App.js引用。

2. 无依赖感知：concat把所有JS文件线性拼接，但App.js可能只用到了lib/utils.js里的debounce函数，却被迫加载整个utils.js。Grunt既不分析require('./utils')，也不理解define(['utils'], ...)，它只认文件名。

3. 构建产物不可预测：uglify输入是dist/bundle.js，输出是dist/bundle.min.js，但这个bundle里到底包含哪些模块？哪些被tree-shaken？哪些重复打包？Grunt完全不提供元信息。我们曾遇到线上报错Uncaught ReferenceError: $ is not defined，排查三天才发现jquery.js被concat漏掉了——因为某次合并分支时，src/lib/jquery.js的路径在Gruntfile里被误删了一行通配符。

提示：Grunt的“可靠性”恰恰来自它的简单——它不做任何假设，只执行指令。但当项目规模超过5万行代码、模块间依赖深度超4层时，这种“不假设”就变成了“不可维护”。

2.2 Webpack的“依赖图谱”引擎：从静态分析到动态执行

Webpack的破局点在于将构建过程升维为图论问题。它不操作文件，而是解析模块语法（ESM、CommonJS、AMD），构建一张有向无环图（DAG）：节点是模块，边是import/require关系。这张图既是编译输入，也是运行时加载依据。以下代码是Webpack能“读懂”的：

// src/App.js import React from 'react'; import { Button } from './components/Button'; import { Chart } from './charts/LineChart'; export default function App() { return <div><Button /> <Chart data={fetchData()} /></div>; } // src/charts/LineChart.js import * as d3 from 'd3'; // Webpack会识别此依赖并加入图谱 export function Chart({ data }) { /* ... */ }

Webpack执行流程的关键阶段：

1. 入口解析（Entry Resolution）：从entry: './src/App.js'开始，递归解析所有import语句。
2. 模块创建（Module Creation）：为每个文件生成NormalModule实例，记录其源码、依赖列表、导出标识。
3. 图谱构建（Graph Building）：将模块作为节点，import关系作为有向边，形成完整DAG。此时App.js→Button.js→Button.css的链路已明确。
4. 优化阶段（Optimization）：基于图谱执行splitChunks（按模块共用频次切分）、tree-shaking（标记未使用的export）、scope-hoisting（合并作用域减少闭包开销）。

这个过程让Webpack获得Grunt永远无法企及的能力：

• 精准的代码分割：splitChunks.chunks: 'all'会自动将node_modules/react提取为vendors~react.chunk.js，而src/components/Button因被多个页面引用，单独生成Button.chunk.js——无需手动配置路径。
• 真正的按需加载：import('./pages/Dashboard').then(module => render(module.default))会被转译为动态__webpack_require__.e()调用，生成独立chunk并注入HTML。
• 运行时模块系统：浏览器中__webpack_require__(moduleId)函数直接模拟Node.js的模块加载，import()返回Promise，require.ensure控制加载时机——构建工具和运行时达成协议。

注意：Webpack的图谱不是静态快照。当你在开发中修改Button.js，Webpack Dev Server通过文件监听触发局部图谱更新，仅重新编译受影响的模块及其下游，而非全量构建。这是HMR（热模块替换）的技术根基，而Grunt连“局部构建”概念都不存在。

2.3 代际差异的本质：从“文件流”到“依赖流”

我们可以用一个生活化类比理解两者的区别：

• Grunt像一家传统印刷厂：编辑把文稿（源码）交给排版组（jshint），排版完送印刷组（concat），印好再送装订组（uglify）。每道工序只认纸张编号（文件路径），不知道这篇文稿是否引用了另一篇的图表（模块依赖）。
• Webpack像一家智能出版社：编辑提交电子文稿（入口文件）后，AI系统自动扫描全文，识别所有交叉引用（import）、图表来源（import './chart.js'）、附录链接（import('./admin.js')），然后动态生成最优出版方案——哪些内容印在主书（entry chunk），哪些做附录（async chunk），哪些由读者扫码下载（dynamic import）。

这个差异导致工具链设计哲学的根本分裂：Grunt插件生态围绕“如何更好搬运文件”展开（如grunt-contrib-copy优化文件复制速度），而Webpack Loader/Plugin生态围绕“如何改造依赖图谱”展开（如babel-loader在模块解析时转译语法，html-webpack-plugin根据图谱自动生成<script>标签）。当React/Vue等框架推动组件化成为标准，当TypeScript要求构建时类型检查，当微前端需要运行时沙箱隔离——所有这些需求，都天然要求一个能理解“模块关系”的构建系统。Grunt的文件搬运范式，在这个时代，已经不是“不够好”，而是“根本不在同一个维度上”。

3. 开发体验的范式重构：HMR、SourceMap与Dev Server的三位一体

3.1 Grunt的“构建-刷新”循环：效率瓶颈的根源

在Grunt时代，前端开发的典型工作流是：

1. 修改src/app/main.js
2. 保存文件
3. 切换到终端，敲grunt watch（或等待预设的watch任务触发）
4. 等待jshint→babel→concat→uglify→copy全链路执行（平均耗时8–15秒）
5. 切换到浏览器，按Ctrl+R强制刷新
6. 查看控制台错误，定位问题，回到第1步

这个循环的致命伤在于反馈延迟。8秒构建时间中，真正用于代码转换的可能只有2秒，其余6秒消耗在：

• 文件系统遍历（grunt-contrib-watch扫描src/**/*下的所有文件变更）
• 进程启停开销（每次uglify都fork新Node进程）
• 无意义的全量处理（concat仍会读取所有JS文件，即使只改了一个）

更严重的是状态丢失：刷新浏览器后，React组件的state、Redux store、表单输入值全部清空。调试一个需要5步操作才能复现的UI bug，意味着每天要重复点击200次。我们曾为调试一个下拉菜单的z-index层级问题，连续刷新47次——这已经不是开发，是体力劳动。

实操心得：Grunt的watch任务常因文件句柄泄漏崩溃。我们不得不在Gruntfile.js里加spawn: false参数禁用子进程，但这又导致uglify阻塞主线程，UI卡死。最终妥协方案是：开发时禁用uglify，只保留jshint和concat，上线前再单独跑一次grunt build。这种“开发/生产双配置”本身就是工程倒退。

3.2 Webpack Dev Server：构建与服务的融合体

Webpack 1.0发布时，webpack-dev-server（WDS）不是附属插件，而是战略级组件。它将三件事融合为一个进程：

• 模块图谱的实时维护（In-Memory Module Graph）
• 增量编译引擎（Incremental Compilation）
• HTTP服务与WebSocket通信（Hot Module Replacement Protocol）

其工作流变为：

1. 修改src/components/Button.js
2. 保存文件
3. WDS监听到变更，立即启动增量编译：
   • 仅解析Button.js及其直接依赖（如Button.css）
   • 复用之前缓存的React、d3等vendor模块
   • 生成新的Button.chunk.js（哈希值变化）
4. 通过WebSocket向浏览器推送“更新模块ID列表”
5. 浏览器端HMR Runtime接收指令，卸载旧Button模块，注入新模块，调用module.hot.accept()回调更新UI

整个过程耗时300–800ms，且不刷新页面。组件state、滚动位置、网络请求状态全部保留。这才是现代前端开发的呼吸感。

关键实现细节：

• 内存文件系统（MemoryFS）：WDS不将编译结果写入磁盘，而是存在内存中。/static/js/main.js请求直接由内存映射响应，避免磁盘I/O。
• 模块热替换API：开发者需在模块中显式声明接受更新：

  // src/components/Button.js import React from 'react'; function Button() { return <button>Click</button>; } // HMR生命周期钩子 if (module.hot) { module.hot.accept(); // 接受自身更新 } export default Button;

  当Button.js变更，WDS Runtime会调用module.hot.dispose()清理旧模块副作用（如移除事件监听），再执行新模块代码。
• SourceMap的精准映射：Webpack的devtool: 'eval-source-map'模式，为每个模块生成独立SourceMap，浏览器报错时直接定位到src/components/Button.js:12:5，而非bundle.js:12345:67。Grunt的grunt-contrib-uglify虽支持SourceMap，但因缺乏模块上下文，映射常错位。

3.3 构建配置的收敛：从“任务拼图”到“单一入口”

Grunt的配置是离散的：jshint有自己的选项，babel有自己的.babelrc，uglify有自己的压缩级别，copy有自己的路径映射。一个中型项目往往有12+个Grunt插件，配置分散在Gruntfile.js、.jshintrc、.babelrc等5个文件中。新人入职第一周，主要任务是搞懂这些配置如何协同。

Webpack将一切收敛为一个配置对象：

// webpack.config.js module.exports = { entry: './src/index.js', output: { path: path.resolve(__dirname, 'dist'), filename: '[name].[contenthash].js' }, module: { rules: [ { test: /\.js$/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-env'] } } }, { test: /\.css$/, use: ['style-loader', 'css-loader'] } ] }, plugins: [ new HtmlWebpackPlugin({ template: './src/index.html' }), new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' }) ], devServer: { hot: true, port: 3000 } };

这个配置的威力在于声明式约束：

• rules定义“所有.js文件必须经babel-loader处理”，不再需要grunt-contrib-babel插件。
• plugins中的HtmlWebpackPlugin自动将<script>注入HTML，取代grunt-contrib-htmlmin的手动模板维护。
• devServer内嵌开发服务器，无需grunt-contrib-connect。

我们曾统计一个10人前端团队的配置维护成本：Grunt项目平均每月花费17人时修复配置冲突（如babel版本升级导致uglify报错），而Webpack项目在2年周期内，仅需3次配置调整（均因Webpack主版本升级）。这种稳定性不是偶然——它是“单一事实源”（Single Source of Truth）原则在工程配置上的胜利。

4. 生态扩展模型的降维打击：Loader/Plugin vs Task/Contrib

4.1 Grunt插件的“黑盒”困境：职责模糊与组合爆炸

Grunt插件生态遵循“一个插件，一个任务”的原子化原则。grunt-contrib-jshint只做代码检查，grunt-contrib-uglify只做压缩，grunt-contrib-cssmin只做CSS压缩。这种分工看似清晰，实则埋下三大隐患：

1. 职责边界模糊：grunt-contrib-sass编译Sass，但grunt-contrib-cssmin压缩CSS——那么Sass编译后的CSS该由谁压缩？若在sass任务后加cssmin，则cssmin需读取sass的临时输出目录；若在concat后加cssmin，则concat必须先合并所有CSS。没有统一协调者，团队只能靠文档约定。

2. 组合爆炸：要支持ES6+TypeScript+PostCSS，需安装grunt-contrib-babel、grunt-contrib-typescript、grunt-postcss三个插件，并手动编写执行顺序：

   grunt.registerTask('build', ['typescript', 'babel', 'postcss', 'concat', 'uglify']);

   一旦typescript输出的JS需经babel转译（如TSX文件），顺序就变成['typescript', 'babel', 'postcss', ...]。顺序错一位，构建即失败。

3. 错误隔离失效：grunt-contrib-uglify报错时，只显示UglifyJs Error: Unexpected token punc «{»，但不告诉你这个{来自哪个文件。因为uglify只接收concat输出的bundle.js，已丢失原始文件上下文。

我们曾为解决一个grunt-contrib-imagemin的PNG压缩失败问题，花了两天时间：

• 第一天：确认imagemin版本兼容性（v5.3.0有bug，需降级到v5.2.1）
• 第二天：发现grunt-contrib-imagemin插件未及时升级imagemin依赖，需手动npm install imagemin@5.2.1 --save-dev并patchnode_modules/grunt-contrib-imagemin/tasks/imagemin.js

这种“插件套插件”的维护模式，在Grunt生态中是常态，而非例外。

4.2 Webpack Loader：模块级的“管道过滤器”

Webpack Loader的设计哲学是函数式编程：每个Loader都是一个纯函数，接收源码字符串（或Buffer），返回转换后字符串（或Buffer），并可附加SourceMap。Loader链（Loader Chain）通过!符号连接，形成Unix风格的管道：

// webpack.config.js module.exports = { module: { rules: [ { test: /\.tsx?$/, use: [ { loader: 'ts-loader', options: { transpileOnly: true } }, // TS→JS { loader: 'babel-loader', options: { presets: ['@babel/preset-env'] } } // JS→兼容语法 ] } ] } };

这个链条的精妙之处在于：

• 上下文保真：ts-loader输出的JS代码，直接作为babel-loader的输入，babel-loader的SourceMap会叠加在ts-loader的SourceMap之上，最终浏览器报错精准定位到.tsx源码。
• 按需加载：test: /\.tsx?$/确保只有TS/TSX文件经过此链，CSS文件完全不参与，避免无谓开销。
• 可插拔性：若某项目不需要Babel（如只支持现代浏览器），直接删除babel-loader配置即可，不影响TS编译。

Loader的标准化接口（pitch函数、normal函数、异步支持）让生态爆发成为可能：

• raw-loader：将文件作为字符串导入（import html from './template.html'）
• url-loader：小图片转Base64，大图片输出文件（limit: 8192）
• i18n-loader：根据import messages from './locales/en.json'自动注入国际化数据

注意：Loader不处理模块依赖关系，只做文本转换。import语句的解析、模块图谱的构建，由Webpack核心完成。这种关注点分离，让Loader可以极度轻量——raw-loader源码仅20行。

4.3 Webpack Plugin：图谱级的“编译期钩子”

如果说Loader是模块级的“文本处理器”，Plugin就是图谱级的“编译期指挥官”。它通过监听Webpack生命周期事件（如compilation、emit、done），在关键节点注入逻辑。一个Plugin的最小骨架：

class MyPlugin { apply(compiler) { compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => { // compilation.assets 是内存中的所有产出文件 Object.keys(compilation.assets).forEach(filename => { if (filename.endsWith('.js')) { const source = compilation.assets[filename].source(); // 在JS文件末尾注入版权信息 compilation.assets[filename] = new RawSource( source + '\n/* Copyright 2024 */' ); } }); callback(); }); } }

Plugin的强大在于它能操作整个构建产物图谱：

• HtmlWebpackPlugin：读取compilation.modules，分析哪些模块被import()动态引入，自动生成<script>标签并注入HTML模板。
• SplitChunksPlugin：遍历compilation.chunks，计算模块引用频次，按minSize、maxAsyncRequests等策略切分chunk。
• DefinePlugin：在编译期将process.env.NODE_ENV替换为字面量'production'，让UglifyJS能安全删除if (process.env.NODE_ENV !== 'production') {...}代码块。

这种能力让Webpack Plugin能解决Grunt插件永远无法触及的问题：

• Tree-shaking：TerserPlugin（Webpack 5内置）在optimizeChunkAssets钩子中，分析AST，标记未使用的export，并在emit阶段移除。Grunt的uglify只看到最终字符串，无法做此分析。
• 资源指纹：output.filename: '[name].[contenthash].js'中contenthash由Webpack在compilation阶段计算每个chunk内容的MD5，确保内容不变则hash不变。Grunt需用grunt-filerev插件额外扫描文件，且无法保证与concat输出一致。

我们曾用一个自研Plugin解决微前端场景的难题：

// MicroFrontendPlugin.js class MicroFrontendPlugin { apply(compiler) { compiler.hooks.emit.tap('MicroFrontendPlugin', compilation => { // 遍历所有chunk，为每个非vendor chunk注入全局变量 compilation.chunks.forEach(chunk => { if (!chunk.name.startsWith('vendors')) { const runtimeCode = ` window.__MICRO_APP__ = window.__MICRO_APP__ || {}; window.__MICRO_APP__['${chunk.name}'] = __webpack_require__; `; // 注入到chunk开头 const originalSource = compilation.assets[chunk.files[0]].source(); compilation.assets[chunk.files[0]] = new RawSource(runtimeCode + originalSource); } }); }); } }

这个Plugin让子应用无需修改源码，即可被主应用通过window.__MICRO_APP__.dashboard动态加载——这是Grunt插件生态中根本不存在的抽象层级。

5. 实操迁移指南：从Grunt到Webpack的避坑路线图

5.1 迁移决策树：什么情况下必须迁？什么情况下可暂缓？

并非所有Grunt项目都急需迁移。我们总结出一套基于ROI（投资回报率）的决策树：

我们曾拒绝为一个政府内部OA系统（jQuery+IE8兼容）做Webpack迁移——其Grunt构建稳定运行5年，迁移成本远高于收益。但为一个日活百万的在线教育平台，我们用3周完成Grunt→Webpack 4迁移，首月构建时间从14.2秒降至1.8秒，CI流水线成功率从76%升至99.4%。

提示：迁移不是“重写”，而是“渐进式接管”。第一步永远是：在Grunt中并行运行Webpack，验证基础功能。用grunt-webpack插件，让Grunt的build任务同时触发webpack --mode=production，对比产物一致性。

5.2 分阶段迁移实施：从“Hello World”到“全量接管”

阶段一：静态资源托管（1天）

目标：用Webpack Dev Server替代grunt-contrib-connect，获得HMR基础体验。

• 创建webpack.config.dev.js：

  module.exports = { entry: './src/index.js', mode: 'development', devServer: { hot: true, port: 3000, open: true }, module: { rules: [{ test: /\.js$/, use: 'babel-loader' }] } };

• 在package.json添加脚本："dev": "webpack serve --config webpack.config.dev.js"
• 关闭Grunt的connect和watch任务，用npm run dev启动。此时页面可热更新，但样式、图片仍走Grunt流程。

阶段二：CSS与资源接管（3天）

目标：Webpack处理所有样式、字体、图片，Grunt仅剩HTML模板。

• 添加style-loader、css-loader、file-loader：

  rules: [ { test: /\.css$/, use: ['style-loader', 'css-loader'] }, { test: /\.(png|jpg|gif)$/, use: 'file-loader' } ]

• 用HtmlWebpackPlugin生成HTML：

  plugins: [new HtmlWebpackPlugin({ template: './src/index.html' })]

• 删除Grunt的grunt-contrib-cssmin、grunt-contrib-imagemin等插件。此时index.html由Webpack自动生成，<link>和<img>路径自动注入。

阶段三：模块化重构（5–10天）

目标：将全局变量式开发（$.fn.plugin）转为ESM模块，启用Tree-shaking。

• 将src/lib/utils.js改为：

  export function debounce(func, wait) { /* ... */ } export function throttle(func, limit) { /* ... */ }

• 在App.js中：

  import { debounce } from './lib/utils'; // 不再使用全局$._debounce

• 启用mode: 'production'，观察dist目录下是否生成utils.js的独立chunk。若未生成，检查sideEffects: false是否在package.json中声明。

阶段四：Grunt退役（1天）

目标：完全移除Grunt，所有任务由Webpack+Scripts接管。

• 删除Gruntfile.js、node_modules/grunt-*
• package.json脚本：

  "scripts": { "dev": "webpack serve", "build": "webpack --mode=production", "lint": "eslint src/", "test": "jest" }

• CI配置中，将grunt build替换为npm run build。

实操心得：最大的坑不是技术，而是团队认知同步。我们为迁移准备了3份材料：

1. 《Webpack速查手册》：一页纸，列出Grunt常用任务对应Webpack配置（如grunt-contrib-uglify→TerserPlugin）
2. 《HMR调试指南》：截图演示如何在Chrome DevTools中查看HMR日志、强制刷新模块
3. 《构建性能监控看板》：用speed-measure-webpack-plugin生成各Loader耗时饼图，直观展示迁移收益

5.3 常见问题速查表与独家解决方案

最后分享一个小技巧：用webpack --progress --color命令，实时查看各模块编译进度。当看到92% chunk assets processing卡住时，大概率是某个Loader（如image-webpack-loader）在处理大图。此时可临时注释该Loader，快速定位瓶颈——这比翻阅Grunt的verbose日志高效十倍。

6. 后续演进：从Webpack到现代构建体系的再思考

Webpack的胜利不是终点，而是前端工程化持续进化的起点。当我们今天谈论Vite、Turbopack、Rspack时，它们并非否定Webpack，而是站在其肩膀上解决新问题：

• Vite的核心创新是“用ESM原生特性替代打包”——开发时直接import源码，利用浏览器ESM支持实现毫秒级HMR；生产时才用Rollup打包。这解决了Webpack“启动慢”（首次编译需构建完整图谱）的痛点。
• Turbopack（Next.js官方构建工具）将Rust性能注入Webpack理念：用swc替代babel做JS/TS转换，用lightningcss替代postcss，编译速度提升10倍。但它依然保留import()动态加载、splitChunks代码分割等Webpack范式。
• Rspack（字节跳动开源）用Rust重写Webpack核心，兼容Webpack配置，但将模块解析、图谱构建等CPU密集型任务并行化，构建速度提升3–5倍。

这印证了一个事实：Webpack定义的模块化构建范式（依赖图谱、HMR、Loader/Plugin）已成为行业标准，后续工具都在此框架内优化性能，而非推翻重来。Grunt的消亡，不是因为它“差”，而是因为它的设计哲学——基于文件的任务流——无法承载现代前端对“模块关系”的深度诉求。

我个人在实际迁移中体会最深的是：工具的选择，本质是团队工程能力的投影。当一个团队还在用Grunt手动管理jquery.min.js和bootstrap.min.js的加载顺序时，他们需要的不是Webpack教程，而是模块化开发的思维训练。而当团队能自然写出import { createApp } from 'vue'时，Webpack只是他们表达意图的顺手工具。所以，如果你正面临类似选择，别问“Webpack好不好”，先问：“我们的代码，是否已经准备好被当作模块来理解？”——答案就在你下一行import语句里。