距离 Webpack 5.0 发布已经过去五年，这期间它主要在进行修修补补，没有太多令人眼前一亮的变化。与此同时，Vite 和 Rspack 相继崛起，Webpack 的发展似乎陷入了停滞。说实话，如果你脑海里对 Webpack 的印象还停留在老旧、缓慢、过时，那你的感觉并非没有道理。
最近，Webpack 刚刚公布了其面向 2026 年的发展路线图，沉寂了五年的官方博客也终于再次更新！
自从五年前 Webpack 5.0 问世后，它一直在进行维护性的更新，缺乏突破性的创新。面对 Vite、Rspack 等后起之秀的冲击，Webpack 的步伐显得有些踌躇。
老实说，如果你对 Webpack 的认知仍然停留在过去那种“老态龙钟”的形象上，这种想法其实并不为过。
然而，看完这份路线图后，我的个人感受是：它确实老了，也确实慢了，但至少能看出来——它并没有打算彻底“躺平”。
甚至可以说，它终于开始正视现实了。
这一次，Webpack 传递出的信号其实相当明确：它并不打算去和 Vite、Rspack 比拼谁更快，而是选择了回过头来，直面自己这些年积累下来的种种问题，准备一点一点地着手清理。
开始偿还“插件债”
Webpack 过去最大的症结，其实并非“做不到”，而是“太绕了”。
很多你日常开发需要的功能，实现本身并不复杂，但想在 Webpack 里用起来，就得一层层往上叠加插件、loader 和各种配置约定。
东西是能跑起来，但非常笨重，也很容易让人望而却步。
而在这份路线图里，它终于准备动手了：CSS Modules 要内置，TypeScript 转译也准备内置，甚至连以 HTML 作为入口这种需求，都不想再让你额外安装插件了。
说白了，就是把以前那套“默认你很懂 Webpack”的前提，往回收一收。
这一步本身，其实和性能关系不大。
它更像是在承认一件事：Webpack 的问题，从来不是不够强大，而是过于复杂。
这一点，恰恰与 2025 年 State of JS 调查报告中的开发者反馈对上了——对大多数开发者而言，构建工具最磨人的地方，早已不是速度慢，而是配置起来太麻烦。
一个不起眼但很关键的方向
如果只是扫一眼路线图，“通用 target”这件事其实很容易被忽略。
但我反而觉得，这是 Webpack 少有的一次具有“前瞻性”的动作。
他们正在尝试的，是让构建结果不再死死绑定在 Node.js 环境上，而是尽可能输出更纯粹的 ESM 模块，然后交给不同的运行时去消化。
无论是浏览器、Node.js，还是 Deno、Bun，都在它的目标范围之内。
这背后其实是一个很现实的判断：Node.js 早已不再是工程领域里唯一的中心。
Webpack 也不想再只为那套“Node.js 加浏览器”的老旧组合服务。
Webpack 也开始正视性能，但…
你在这份路线图里，看不到那种“性能提升 X 倍”的激进宣言。
但有一个变化其实挺有意思的：Webpack 已经不再假装自己活在真空里了。
这次路线图里提到的一些优化方向，比如 Lazy Barrel，其实就是直接参考了 Rspack 已经验证过的思路。
这在以前是很少见的。
Webpack 过去更习惯于自己慢慢打磨，而不是回头看看别人是怎么做的。
而现在，它开始承认：有些问题，已经有人用更好的方式解决过了。
当然，这些改动谈不上激进，更多还是止血级别的优化：减少无效构建、收敛插件链路、探索最新的多线程能力。
Webpack 很清楚，它追不上整条 Rust 工具链的速度，但至少不再无视那些已经被验证过的正确方向。
还有一条线：纯粹是在清理历史债务
CLI、开发服务器、文档，这一整块内容，说白了就是在“还旧账”。
CLI 要重整，开发服务器那一堆能力要拆、要合、要插件化，文档干脆准备从类型定义和结构描述里自动生成，减少人工维护。
这些东西写出来一点也不“性感”，但不得不做。
Webpack 这些年欠下的工程债，确实太多了。
那 Webpack 现在还值得用吗？
其实路线图已经替它回答了。
Webpack 已经不再想当“最快的那个”了，它选择继续站在复杂工程、深度定制、长期维护这一边。
如果你是启动新项目，或者是中小型项目，或者你特别在意构建反馈速度，那 Webpack 大概率不会是你的第一选择。
但如果你维护的是那种体量庞大、历史包袱重、牵一发而动全身的工程，Webpack 至少在一件件事上：保证你不会在半路被抛下。
写在最后
Webpack 这次的转向，与其说是反击，不如说是自救。
它终于开始承认世界已经变了，也终于开始把这些年该补的课，慢慢补回来。
不讨喜，也不性感。
但确实很 Webpack。
