Webpack5 核心原理与应用实践

打开招聘需求，构建工具一栏写着「熟悉 Webpack 配置与优化」的岗位仍然占大头，可真正能说清楚「一次 npm run build 背后发生了什么」的人并不多。这门课面向的正是这个缺口：不是教你把配置复制粘贴到项目里跑通，而是把 Webpack 5 的运转逻辑拆开看。

先判断自己缺的是哪一块

Webpack 的学习难点不在 API 数量，而在它的抽象层次。多数人卡住的位置其实很集中：

• 会改 loader 和 plugin，但说不清一个模块从入口到输出经历了哪几个阶段，遇到 loader 顺序问题只能靠试。
• 知道 code splitting、Tree-shaking 这些名词，但项目里打包体积降不下来，也不知道从哪里入手定位。
• HMR 配好了能热更新，可一旦报错就绕过，不理解它和 devServer、模块依赖图之间是什么关系。
• 写自定义 plugin 时对着 compiler、compilation、tapable 的 hooks 发懵，不知道挂哪个钩子、拿到的参数是什么。

如果你对以上任何一条有共鸣，说明缺的不是「再多记几个配置项」，而是构建流程的完整图景。这门课按场景搭建、性能优化、组件开发、源码原理四段递进，正好对应上面四类问题。

这门课真正要讲清的东西

Webpack 5 的内核规模不小——近 500 个 JS 文件、400 多个类，几万行代码配两万行注释。把这一整套读一遍不现实，也没必要。课程的处理方式是从可验证的行为切入：模块打包、代码分割、按需加载、HMR、Tree-shaking、文件监听、Sourcemap、Module Federation、devServer 这些能力，各自在什么条件下生效，背后依赖哪些机制。

Loader 与 Plugin 的开发部分值得单独说。这两者是最容易「会用不会写」的地方：Loader 本质是对模块源码的转换函数，Plugin 则是借助 Tapable 挂载到构建生命周期的钩子。理解了这两条，你才能判断一个现成的插件在构建流程的哪个时点介入、为什么有时和另一个插件冲突。

性能优化不是孤立的一节，它和源码原理是一体两面。构建速度慢，可能是 loader 的 include/exclude 没收敛、可能是 sourcemap 类型选重了、可能是缓存策略没落地；产物体积大，则要回头看 Tree-shaking 的生效前提、splitChunks 的切分粒度、以及模块是不是被意外全量引入。这些都需要能读懂 stats 输出、能定位到具体模块。

看完应该能回答的问题

• 一个 entry 从解析、依赖收集、转换到生成 chunk，中间的状态分别由哪些对象持有？
• 为什么某些写法会让 Tree-shaking 失效？sideEffects 字段到底影响了哪一步？
• HMR 更新时，是哪些模块被替换、哪些状态被保留？为什么有时候热更新会退化成整页刷新？
• 要写一个「打包结束后把产物清单写入文件」或「把某个依赖替换成 CDN 地址」的插件，你会挂哪几个钩子？
• 面对一个构建耗时 60 秒的项目，你会按什么顺序排查，每一层预期能拿回多少时间？

怎么用这份资料

建议不要顺着从头看到尾就完事。先挑自己项目里最痛的一个问题——构建慢、包太大、还是不敢改配置——带着它去看对应章节，边看边在真实项目上验证。原理部分可以放在后面，等你对现象有了手感，再回去看源码级的实现会顺畅得多。练习的重点不是敲一遍示例，而是每学完一块，能对着自己的 webpack 配置说出「这一行做了什么、去掉会怎样」。说不出来的地方，就是你还没补上的缺口。