webpack/rspack/vite对比

前几天，我让AI帮我写一个基于electron的简易爬虫软件。这里首先感慨一下，AI完成得挺不错，像这样的Demo小项目，AI已经具备了完全自主、一次写成的能力。

但是让我稍微有些意外的是，ai生成的代码中，前端构建工具选用的是vite，而不是更经典的webpack。

我查看了它的配置文件vite.config.js，又一次感到意外——这份配置过于简洁了，只用10行代码就描述了一个简易的web项目。

于是我产生了兴趣，对目前主流的三个构建工具：webpack / rspack / vite 做一个性能上的对比。

测试用的代码，是我们项目组的前端主仓库，总代码量40万行，其中web网页端大约涉及其中的10万行代码（粗略估计）。

使用webpack的情况：

• （在一台老硬件上的CI）dev构建需要110秒
• （在研发本地电脑上）serve服务启动需要29秒
• 修改之后的重编译大约需要1秒多，需要显著地等待再刷新
• dev构建需要25秒
• prod构建需要60秒

必须说明的是，webpack并不是它最巅峰的状态。我所采用的js转换器是babel，并没有采用更快的esbuild或swc。

接下来是rspack。

我让AI帮我重构，它改动的代码只有十行左右，但是随后我手动测试还是遇到一些问题，经过我手动调整了大概4处配置后，运行正常。甚至包括我自己写的几个Plugin也无缝兼容。

这可以说明，尽管有些细节差异，但rspack与webpack的配置绝大部分是相同的，其中最重要的是，二者的配置的编写思路是相同的，具备webpack经验的前端程序员可以很快将他们的经验和成熟的代码迁移到rspack上。这是一个巨大的优势，这在工程上很重要。

rspack的成绩为：

• serve服务启动需要10秒
• 修改重编译速度很快，忽略不计
• dev构建需要10秒
• prod构建需要12秒

由此可以看出，rspack的构建速度大约是webpack的3~5倍。

接下来是vite。

我个人对vite几乎毫无经验，因此也是同样地交给AI完成。第一次尝试由Gemini 3.0 Pro执行，但是它失败了，由于@vitejs/plugin-react插件对本机的nodejs版本有要求，Gemini一直无法成功安装，一直循环尝试并一直失败。第二次尝试由Gemini 3.1 Pro执行，经过一番尝试后它成功地安装了可用的依赖版本，完成了配置的重构。

vite的成绩为：

• serve服务启动需要0.7秒
• 修改重编译速度很快，忽略不计
• dev构建需要27秒
• prod构建需要26秒

为什么vite的serve服务如此之快？原因在于：它完全地跳过了”bundle”这个步骤，它几乎是以类似静态文件服务器的方式，向浏览器提供“原始”的文件。稍微具体一点说：

• 它在启动时不会处理js代码，它只提供.html入口文件；
• 当浏览器加载并解析html后，根据其中的内容请求后续的资源，例如<script type="module" src="/src/index.ts">；
• vite收到localhost:8080/src/index.ts的请求，调用esbuild等工具进行转换后提供；
• 对于index.ts中import了a.ts, b.ts, c.ts，浏览器分别继续请求localhost:8080/src/a.ts等文件
• 如此递归请求，直到所有依赖文件加载完成。

因此，这种所谓“模块化”、“按需加载”的架构，虽然看起来“启动速度很快”，但实际上，它的代价是浏览器第一次打开页面时，需要发起大量的请求（在本例中发起了约500个http请求），导致速度很慢（需要多等待大约5秒）。本质上它是将构建所需要的时间，拖延到了加载阶段再用，嘲讽地说，这妥妥属于一种“赢学”。综合算下来并不比rspack更快。这里它能比rspack略快，我估计是由于lazy模块让它成功偷懒了，否则我估计它的加载时间应该与它自己的dev构建时间相近才对。

在使用vite的过程中我还遇到一个无法解决的问题：它的dev server仅接受来自localhost的请求。而在我们的实际开发场景中，我们会通过使用PAC代理，将company.com的域名转发到localhost:8080上，而这种情况vite的服务器会响应404，这种莫名其妙的域名限制策略让我无法理解。

vite所用的js转换器是esbuild，由golang编写的它，虽然比js原生的babel更快，却也比rust编写的swc更慢。当切换使用@vitejs/plugin-react-swc之后，它的编译速度略有提升，dev和prod构建需要20秒。提升不算很显著，理由是transform虽然是最重的阶段之一，但并不是全部。

综上所述，如果webpack的速度是1倍，那vite速度大约是1.5倍，rspack的速度大约是4倍。

显然，vite基于esbuild和按需编译所带来的少许性能优势，完全不能弥补其在配置文件语法上“自成一派”所带来的坏处。

作为一名架构师，我还有讨厌vite的另一个更重要的理由：它的设计理念是高度针对浏览器特化的，并不适应“大前端”——例如electron客户端、nodejs中间件等——的开发需求。前端切图崽选择vite（类似的还有vue）的理由无非就是两点：一是开发阶段启动快，二是配置文件更好写；前者我已经在本章节中通过实战证明了，而后者我只能说：“这种简单的需求难道不能通过复制模板来实现吗？”。它的官网甚至敢自称“Next Generation Frontend Tooling”，我不懂他们在嗨些什么。

typescript-go

项目代码量变得巨大以后，不只是webpack会带来等待的痛苦，eslint、tsc等检查工具也面临同样的问题。

这时我想起了，大约在一两年前，我听说了“typescript编译器将用golang重写”的重磅新闻（官方博客，文字和讨论）。现在它怎样了呢？

简而言之：可能快了，已经有了预览版 。

与前一章节相同，我使用我们项目组现有的代码仓库进行测试。结果为：tsc v5运行时间约30秒，而tsgo运行时间约4秒。确实符合其博客所说“10倍的性能提升”。

不过遗憾的是，由于 typescript v7，或者准确地说应该是从v6开始，类型检查变得严格了，因此新版的tsc v6/tsgo尝试用在我们现有的代码仓库中时，会抛出无数的类型错误（以Null值类型赋值问题为主），也就是说，不能（或者说很难）真正用在我们现有的仓库中，只能在新项目中启用。

颇为搞笑的是，在YouTube的采访视频中，有一条搞笑评论：“Damn Go bros are eatin good today”。

那么作为golang的支持者，我在这里简单归纳一下，为什么ts选择用golang重写：

与js相比，golang的性能很高。将js改写为go，也就是所谓的“原生代码”，可以带来3-3.5倍的性能；而golang的原生并发模型，又可以带来3-3.5倍的性能。二者叠加，能达到10倍的性能。它的内联数据结构，例如struct，有足够优秀的表达力。而GC的负担可以忽略不计。

为什么不用Rust？因为Rust很难写。Rust实际上禁止了循环数据结构，而ts所有的数据结构都是高度循环的。硬要用Rust也不是不行，但考虑到ts的v6与v7是并行开发的，选择Rust并不明智。如果是一个全新的项目从头来过，那么Rust可以是一种选择。

作为微软技术院士、TypeScript首席架构师，Anders Hejlsberg 为什么不选择自家的C#？因为typescript的代码库采用高度函数式的风格编写，与完全面向对象的C#并不兼容。

go由于其高效的内存模型，很轻松地就能实现，相比于用尽骚操作的js代码，运行内存只需要一半。

有意思的是，Rust更像是现代的C++，而Go更像是现代化的 JS/Python 。（许多人都公认这一点，这却与Go的“better c”初衷背道而驰）

一些工程师抱怨说Go太平庸了，不能实现一些花哨的功能，他们很不满意。首席技术官——我永远不会忘记——打断他们说：“你们必须明白，Go的设计初衷就是平庸；它本来就没打算追求花哨。”说实话，它的确很简单。但结果却不平庸。我的意思是，10倍速——这可一点都不平庸，对吧？所以，你可以用它做出很棒的事情。

AI Agent

前几天，我们项目组举办了一次内部编程比赛（或者按他们的话来说称之为“黑客马拉松”），比赛主题为：不限技术、不限功能，限制2天时间，开发一款“与AI有关”的软件。

其中一支参赛队伍的作品，也是我认为最有价值的作品，是一款（Demo级别的）网页小游戏。

它最大的意义在于，几乎完整地打通了利用AI实现从设计到产品落地的完整链路。具体来说，参赛队员有两位，一位设计师，用AI生成图片素材和figma设计稿，一位程序员，利用copilot直接调用figma的MCP接口生成代码。整个过程中AI生成的部分占比高达百分之八九十，人类只是少量地介入，做些修改和优化的工作。就这样就弄出了一款Demo产品，其产品质量，至少“能玩”，如果不考虑ROI的话，再补上广告系统然后投放到微信，理论上至少是能跑通的。

最近一段时间，我也在逐渐尝试着、并且越来越多地开始使用Copilot的Agent模式。当我坐在这位程序员参赛选手旁边目睹他的操作之后，我对Copilot的能力有了一些新的认识，虽然算不上很震惊，但也确实收获良多，产生了一些新的灵感。

另一方面，这款游戏作品，也反映了当下AI存在的问题——它还不够聪明。具体一点说，它目前对人类世界，至少在2D图像方面，还仅仅只是拙劣的模仿，还远远不能理解真实的物理规律。例如，它生成的figma设计稿中的元素，全都是绝对定位，然后据此生成出的前端代码，也相应地都是绝对定位，这样会导致一些奇怪的bug；而换做一个合格的高级前端程序员/游戏程序员来做的话，是会根据自己的理解进行分组分层的。例如，它生成的游戏算法很“僵硬”，运行有bug不说，就算能跑通也不“好玩”，这个环节还是需要人类介入来提供灵感，仔细耐心地打磨，才能产出一套“好玩”的算法。等等。

虽然它还不够聪明，但现在至少可以说，AI Agent已经达到了“可用的的最低水平”。

在上一篇文章中我提到，我认为，在AI时代，程序员们需要用新的模式来设计项目的架构。于是最近我着手重构了几个项目的架构。在这个重构的过程中，AI Agent 表现良好——我提示新的代码架构和旧的代码路径，它可以有效地将代码进行重写，重写之后的代码完成度很高，几乎可以跑通，只需要经过人类的少量手动修改即可。在我的最终代码中，AI产出的代码大约占百分之六七十，实际综合产出效率是以往的两三倍。

模型之间亦有差异。例如我前面提到，Gemini 3.0 Pro会遇到无法解决的问题，而Gemini 3.1 Pro就明显更聪明一个档次，后者大部分情况都能靠自己独立完成工作任务。然而，后者在Copilot中表现得也有些“蛮干”，例如经常调用命令行工具，例如echo来写入文件，而不是调用VSCode提供的Tools，而且还总是用Linux的命令行工具，这在windows平台上失败和重试的次数很多，挺让人操心的。作为对比，GPT-5.4在这方面就聪明太多了，它几乎总是能选用最高效的工具来完成任务。还有一点值得一提的是，GPT的思考过程是中文的，这样便于人类理解和介入；而Gemini的思考过程是英文，即使对于我这种可以不太费力直接阅读英文文本的人来说，要从海量的AI思考过程中快速提取关键信息，依然是个痛苦且几乎不可行的事情。

目前我们最熟悉的、最广泛使用的Agent，Copilot，还只是运行在IDE中，被许多规则束缚着，即使这样，对于包括我在内的很多程序员来说，也依然对它保持着谨慎和防范的态度。而从2026年年初开始逐渐步入大众视野的、另一种更通用的系统级别的Agent，OpenClaw（中文圈内俗称“龙虾”），则更是“野路子”。我个人目前对它持负面态度，静观其变吧。

我写完这篇文章、发布之前，外部世界同时也在快速变化。层出不穷的培训、卖课广告就不说了，甚至还诞生出了“上门安装OpenClaw”的产业，不得不感慨社会的适应性真强，永远不缺钻空子、找商机的人。其火爆程度，甚至引发国家工信部发布专项风险预警，提示如果配置不当极易引发安全问题。确实，对于小白用户来说，它完全可以算是一种木马病毒了。

厨艺

26年春节前后，我投入了大量的时间精力用于烹饪。二十多天的假期，除了在家办公的日子的工作时间，我几乎每天都花大部分时间泡在厨房里。

经过这样集训营式地锻炼后，我的厨艺又上了一个台阶，备菜、刀工、火候、调味和一些小技巧等等，都有明显的进步。直观地体现在，妹妹们开始惦记我的红烧肉，鸡翅；听说我要回来了就知道又有饼干吃了；春节那几天去亲戚家，我很自然地撸起袖子走进厨房，跟七大姑八大姨一起准备大餐。

回头看看，我在2022年也专门写过一篇文章分享我对厨艺的理解。虽然与之前相比我对一部分内容的理解已经发生了变化，但这里我也不再赘述一些基础的东西了，只强调两点近期比较深刻的感触。

第一，烹饪这件事，熟练度是基础，理论是灵魂。不管网上的菜谱再怎么精妙，都必须经过自己动手实践、总结和提炼之后，才能真正成为一道让自己和家人满意的饭菜。“思而不学则殆”可能是很多现代年轻人的常见病症，而相对的，老一辈的人则经常“学而不思则罔”——他们往往在厨房闭门造车，或者只有亲戚间有限的交流。如果真想要“做好菜”的话，实践和理论要两手抓，像在学校读书时那样系统地学习。

第二，思想建设很重要。以此谋生的厨师等职业人士暂且不论，过于贫穷或挑食的人也暂且不论，对大多数一般人来说，请想一想，到底为什么走进厨房？如果仅仅只是为了填饱肚子，那自己做饭显然不划算，不如上街去找找，有些连锁式的自选称重快餐，才会是达成“口味-营养-价格”之间完美平衡的选择。花费在厨房的时间如果换算成工时，那每一顿饭都像下馆子一样昂贵。如果想清楚了这一点，还要坚持“不计代价”地亲自走进厨房，那必然只能是“为了爱”。

以爱之名，适当选用优质新鲜的原料，适当舍弃一些边角料，适当使用复杂精致的工艺，甚至用餐前后的仪式感……都会为饭菜注入神奇的美味魔法。而抱着完成任务的心态走进厨房，那也只配得到敷衍的回应。

长期在厨房活动，我对家居装修也有了不同的理解。虽然在装修时我已经在厨房投入了大量的精力，但毕竟受限于各种各样的原因，总是没能做到完美。如果时光倒流让我重来一次的话，我会继续加大厨房条件在我装修甚至购房时所考虑的比重。现在我认为，厨房（厨餐厅）就该做成“烹饪工作室”，而旁边的客厅就应该做成“电竞工作室/家庭会议室”。家庭成员需要这些公共活动来产生交流。

嫁女的心情

今年除夕的饭桌上，增加了一名新成员——表妹把男朋友带回来了。

虽然我跟妹妹平时交流不算多，但感情还是挺不错的。也许能算是“长兄如父”吧，如今面对“拱白菜的猪”登门拜访，我竟然也产生了一丝“嫁女的心情”——五味杂陈，难以言说。

她爸妈也是第一次当丈母娘，甚至私下里找我询问对这位未来妹夫的看法。其实说实话，以我的阅历来看，这个小伙子算不上很优秀，但是我既不能仅靠几日的相处就对一个人妄加评论，也不便于过度插手亲戚的家事（以及一位独立女性的婚事），所以斟酌语言，给出了一个略带褒义的简单评价：虽然如何如何，但是如何如何。

后来他们谈了一些订婚的条件，包括一个彩礼的金额。这个金额在本地来说算是“中等”，放眼全国可能算是“比较高”。对此我也是颇为感慨，虽然这笔钱对我来说没什么压力，甚至说句难听的，如果用这笔钱可以买下我这位宝贝妹妹，我可以毫不犹豫掏出两倍的金额——就像《骑砍2》中的主角妹妹一样，一辈子带在身边，我也不要她上阵杀敌或者治理一方，只要找一份普通的工作，在家里当一只米虫宝宝就好了——但这显然是不现实的。

矛盾之处在于，一方面在理论上，我是反对高额彩礼的；而另一方面在现实中，我却很难评价彩礼的对与错——也许可能如果万一以后我有自己的女儿，我可以做出我作为一名父亲可以做出的决定，但是我没有资格对别人进行评价。而站在男方考虑，作为同样一名未婚男性，我也很难、或者我不愿意，去想象未来有朝一日如果我的丈母娘提出一个对我来说很有压力的条件，我会作何感想。——不，曾经我差点走到这一步，我可耻地逃避了。

绝区零

春节期间，我尝试使用 switch Joy-Con 手柄，与家人一起游玩steam游戏，结果我被现实的铁锤狠狠教育了——它很难用，而且兼容性很差。

于是在年后，既是为了“报复”，也是为了下次的提前调研，我买了一个 Xbox 手柄。可到手之后我又懵了——手柄确实是好手柄，可是我没人一起玩啊。

鬼使神差之下，我开始玩了一款，我曾经认为我永远也不会尝试的游戏——《绝区零》。

抽卡游戏必须要谈谈抽卡系统。《绝区零》作为典型的米哈游游戏，经典的90抽大小保底“米池”自然是一脉相承。新人入坑能获得的角色都是强度为T3/T4级别的垫底存在。在 2.6 版本入坑的我，已经做好了跳过 2.7 、 2.8 版本的心理准备，提前开始备战 3.0 版本了。确实很毒，光是听着就很扭曲，对吧？

我在之前的文章中也批评过这种重度氪金的机制。但是此时的我似乎变了——我居然开始觉得：抽卡也没那么重要。

“少抽几个角色，又有什么关系呢？”

大大方方地跳过就是了。米哈游一年出18个新角色，我就集中火力，只抽其中强度最高（或者xp最高）的三四个就是了。缺少角色并不会对游戏体验有太大的影响，更没有必要追求“全图鉴”——这种思路在碧蓝航线等偏收集类的抽卡游戏中适用，但既然现在原神、鸣潮、绝区零这类游戏把抽卡看得很“重”，那与其去嘲讽和对抗，不如转变自己的思维，尝试去理解和加入。

缺少角色最大的影响，就是副本队伍凑不齐、强度不够高，导致可能副本奖励拿不满。可是，既然我都已经接受跳过角色了，抽卡资源已经富裕了，也就没必要再追求像打工一样地拿满所有奖励了。你看，心态一旦改变，两难自解。

至于在剧情和互动方面的缺憾，则完全可以从社区二创中获取。在2026年的现在，AI内容满天飞的时代，甚至连一些还没上线的游戏都已经能见到大量的二创内容了，二创早已经比原创剧情更加丰富和精彩。

我这种思维的转变，似乎不仅局限于游戏中，更是存在于我的生活中。与以前相比，我开始变得淡然，不再那么对事物抱有执念，更能接受自己的不完美和失败，更能接受随时拿起一副不完美的手牌尽力打好一局精彩的比赛，而不是强迫自己必须从头经营一副好牌。

言归正传。对于这款游戏，如果抛开抽卡系统不谈的话，我的评价是：非常优秀。

它最出彩的一面是它的动作系统，几乎做到了极致。举个例子，之前让社区津津乐道的一点是，在“楼梯”场景下，游戏角色与楼梯台阶之间的互动。传统游戏往往将游戏角色视为一个整体（用术语来说就是碰撞体类似胶囊形），而绝区零中的角色，其两条腿是分别独立建模、也分别独立与环境发生交互的。这是很能体现其恐怖技术力和精良品质的冰山一角。

我还想提及的另一个方面，是它对游戏手柄的适配堪称完美，或者不如说，手柄就是它立项之初就原生支持的平台之一。按键布局、震动反馈都无可挑剔。与之对比，我尝试在《鸣潮》中使用手柄，就感觉非常不自在，远远不如键鼠的操作体验——当然大世界模式与街机动作类游戏的本质区别也是导致后者无法完美兼容的原因之一。这一点，在我之前总是习惯使用键鼠的时候是完全意想不到的，也成为了我现在入坑这款游戏的重要理由之一。

至于更“常规”的技能特效、打击感、剧情演绎、UI交互等方面，几乎都可以说是顶级，与传统的3A主机游戏相比也毫不逊色。而美术风格、角色设计方面，更是最顶尖的水平，甚至可以不客气地说，米哈游对“二次元”的理解一直以来都处于业界的第一梯队，只有NEXON和黄鸡能分别在不同赛道上与之抗衡。

当然它的缺点也有，除了上面提到的抠门的抽卡系统，还有略显平庸甚至乏味的剧情（第一季前半挺精彩，后半就有点糟糕，特别是雨果和薇薇安那部分），还有缺乏深度、到后期很容易枯燥和长草的战斗系统。以及再强调一遍，米哈游的卡池很毒。前面我夸赞了这么多，后来抽卡给我歪一下，我立马就老实了。米哈游家的游戏，固然精致，但是真要玩的话，我还是奉劝三思、再三思，最好不要入坑。

综合来说，把它作为一个“副游”来看待，不抱有过多的期望、不投入过多的心血的话，它应该能够给人带来一段印象深刻的体验。

年后这段时间，手游市场捷报频传。先是蓝原截止3月17日招募二次内测，后有异环定档4月23日正式公测，两个都是我关注已久的游戏，到时候高低也得尝尝咸淡。两个月后再见吧。