优点：右手设计，趴握舒服，按键清脆。缺点：没有蓝牙，滚轮垃圾。

对称设计 vs 右手设计

人手本身就是一个不对称的结构，而且自然状态下手掌不是水平的，而是与桌面有一个角度的。使用对称鼠标必然要强行让手掌放平，手腕扭曲。而右手人体工学鼠标，通常都是左高右低的斜面，甚至是垂直的面，长期使用手腕更省力。

鼠标左右键通常用食指和中指按压，中指通常明显长于食指。右手鼠标通常采取左键偏下右键偏上的布局，比对称鼠标的点击更加舒服。

握住鼠标左右的是大拇指和无名指（或小拇指），这两个手指差异就更大了，对称式设计要么大拇指不舒服，要么无名指（小拇指）不舒服。而右手设计是左右两面不同的形状：左侧贴合大拇指虎口，右侧贴合无名指和小拇指的第二关节。

我基本上只买右手设计的鼠标，但是现在市面上几乎都是对称设计的鼠标。比如 2023 年两百元价位的国产鼠标三巨头：VGN 蜻蜓 F1，雷柏 VT9Pro，达摩鲨 M3。

V30W 这只右手鼠标我自己感觉握感挺好，18cm没什么肉的手正好贴合。大厂在这个价位都没有右手鼠标卖。虽然比起雷柏家的办公鼠标 MT750L（致敬罗技 MX Master 3）握感还是差一点，但是 MT750L 有点太厚，回报率也低，不适合打游戏时快速移动。

材质

按键表面和手掌位置是类肤质涂层（摸着舒服，但容易油），左右两侧是磨砂塑料带有纹路增强抓力。

重量

重量 86g 属于适中，游戏（速度）和办公（控制）都行。太轻的鼠标不好控制，不适合绘图，做表格。太重的鼠标速度又跟不上，不适合打游戏。

按键

按键清脆，不静音。我们办公室本来就比较吵，所以不太在意。

左右键点击感觉一致。右手鼠标常见的坑就是左右键不对称导致触感不一致，但是这个鼠标没有这个问题。

前进后退键的位置比较好，用大拇指按很舒服。

多了一个开火键，大拇指稍微往前一点就能够到。我平时不玩射击游戏所以用不到。

滚轮

垃圾。

在芬兰，不论是任何宗教，敬而远之是最好的对待方式！

继续阅读 →

最近开源社区最大的新闻就是红帽宣布 RHEL 不再公开源码，而是提供 CentOS Stream 的源码。而在此之前 CentOS 已经从 RHEL 的平替，变成了一个滑稽的滚动发行版。结果导致：

1. 对很多资金紧张的企业来说，CentOS 不能用了；
2. 基于 RHEL 源码的发行版，如甲骨文 Linux，亚马逊 Linux，Rocky Linux，在拿不到 RHEL 一比一源码的情况下，构建将更加困难；
3. 开源社区对于红帽的信任危机，会影响红帽所主导的开源项目。

红帽是否背叛了开源？是否违反了 GPL？

…CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal. …

… Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement.

https://www.redhat.com/en/blog/furthering-evolution-centos-stream

根据红帽目前的说法，RHEL 的源码获取和使用的条件非常苛刻：

1. 只有 RHEL 客户和合作伙伴才能获得 RHEL 的 1:1 源码；
2. 客户和合作伙伴受到协议限制，不能再分发源码或重新构建 RHEL。(如果你做了，就停你许可协议)

第二条显然是律师设计的钻 GPL 空子的做法，但是法庭不一定会支持。就像老板说你今天可以不加班，但是明天我会辞退你，那么这家公司是否允许加班呢？是否违反劳动法呢？法律并不是玩文字游戏。

而第一条，虽然不违反 GPL，但是已经从字面上完全背离了 Open Source 的精神。

后续红帽又发文解释（同一个人，自称做开源十几年），但是这个解释更加令人失望。他似乎并没有意识到自己问题，反而认为是 Linux 社群的人不懂 GPL。让我们来看看他的惊人言论：

We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL. …

I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous. …

https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes

第一点，这个人一直在强调 RHEL 的代码会反馈给 Linux, GNU, GNOME 等上游项目，所以不需要向下游提供源码。但是你 RHEL 是作为一个完整的软件套件分发的，就需要同时分发其对应的源码给用户，并且不得限制用户修改/再分发源码。任何对 GPL 的掺杂附带条件的解释，都是对 GPL 的曲解和破坏。我很期待 RMS 来对红帽的观点进行点评。

第二点，这个人直接将下游利用 RHEL 代码的行为定性为自私自利。但是不要忘了，你红帽做出 RHEL 不也是靠利用上游代码？如果 Linux 和 GNU 都不提供给你源码，你不也一样赚不了钱？甚至红帽 2021 年退出了自由软件基金会，变成了利用 GNU 赚钱却不回馈 GNU。对于红帽的这种双重标准，我只能说是虚伪之极，无耻之极。

职业经理人正在毁掉一切

提到红帽，就不得不提 IBM。

1. 2019 年，IBM 收购红帽。
2. 2020 年，CentOS 卒，走得并不安详。
3. 2023 年，RHEL 背叛开源。

如今的 IBM 已经是一家唯利是图的公司了，近些年几乎毫无创新。职业经理人掌控科技公司就会带来这种问题。而如今他们似乎也想给红帽杀鸡取卵。职业经理人们根本不懂开源，也不懂社区，甚至也不太懂企业客户。任何东西对他们来说都是工具，而他们只为股价和股东负责，为此他们很乐意牺牲任何工具，包括客户。

虽然红帽发文的人自称是资深工程师，但是我从他身上看不到一点开源精神或者社区精神。他更像是典型的大公司雇员，为公司的利益行动。从他的陈述，我们可以一窥红帽内部对于开源的态度。

如今有太多的公司怀着不单纯的目的参与开源。另一个例子是 Google 的 Android AOSP。以前你可以用 AOSP 源码构建一个全功能的移动操作系统。但是当 Android 已经统治了市场，Google 就开始将 AOSP 的功能砍掉，转移到它闭源的 Google Services 里。开源对他们来说只是一种便利的工具，只要符合资深利益，随时可以抛弃。

SUSE，甲骨文，C 社趁虚而入

红帽显然高估了自己对局面的掌控能力。其他厂商迅速做出了回应。

SUSE 宣布将投资 1000 万美元创建一个 RHEL 的开源硬分支。（目前的 openSUSE 和 SLE 发行版不会受到影响）SUSE 的系统和红帽具有很多相似性，比如都采用 RPM 打包格式，包管理器共用一部分代码，Open Build Service 也早就支持 CentOS 和 Fedora。估计创建一个 RHEL 分支并非难事。

甲骨文则是继续推销自家的 Linux，并为开源摇旗呐喊。了解甲骨文发家史的朋友看到这个标题，应该会觉得十分讽刺：Keep Linux Open and Free—We Can’t Afford Not To

C 社应该是最高兴的，Ubuntu 已经是市占率第一了，份额预计会进一步上升。在红帽的降智行为衬托直线，C 社的口碑甚至有所改善。它甚至什么都不用做就能从中受益，赢麻了。

显然，友商对红帽的行为都是不齿的。

一些前车之鉴

甲骨文收购 MySQL 后将其分成了开源的社区版和闭源的企业版。原 MySQL 创始人之一创建了硬分支 MariaDB 并迅速取代了 MySQL 在发行版中预装位置。曾经一度变成小众数据库的 Postgres 也逐渐流行起来。

Qt 公司宣布 Qt 6 将采用订阅模式，而非之前采用的买断模式。Reddit 上有很多企业版客户表示，会继续使用 Qt 5，不会升级 Qt 6。

MongoDB 直接从开源转为闭源，软件包从所有主流 Linux 发行版中被移出。大量客户改用同样支持 NoSQL 特性的 Postgres，或者用亚马逊闭源但免费的兼容数据库 DocumentDB。其 CEO 还丢下一句名言：

we didn’t open source it to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption.

我们的开源并不是为了获得帮助，使产品更好，而是作为免费增值策略，以推动采用。

ElasticSearch 从开源转为闭源，随后亚马逊硬分支了 OpenSearch。现在，OpenSearch 已经比 ElasticSearch 还要流行。

Node.js 曾经短暂出现一个 io.js 硬分支，以表达当时 Node.js 所属公司管理问题导致 Node.js 进展缓慢的不满。后来 Node.js 所属公司怂了，Node.js 改由基金会运营，才结束了分裂。

如果没有用过 Yuzu 模拟器，请先阅读《Switch游戏模拟指南》，再继续以下内容。

硬件需求

与前作《旷野之息》类似，《王国之泪》也是榨干了 Switch 性能。模拟器的硬件要求也比其他游戏要高。

1. CPU：推荐 AMD 3600 / Intel 10400 或更强的 CPU，虽然不是特别吃 CPU，但也不能太弱或太老。
2. RAM：推荐 16GB 以上内存。如果需要 4K 60FPS，则需要开启模拟器的内存扩展，建议 32GB。
3. GPU：推荐 AMD 6600XT / NVIDIA 3060 或更强的 GPU。Intel 的核显独显都跑不动。如果想要稳定 4K 60FPS，建议 AMD 6800XT / NVIDIA 3070Ti 或更强的 GPU。

更新固件

必须更新到 16.0.1 以上的固件才行。注意 prod.keys 也必须匹配固件的大版本号，15.x 固件对应的 prod.keys 在 16.x 固件上不能用。如果不知道如何安装固件，请先阅读《Switch游戏模拟指南》。

解决加载问题

《旷野之息》是能直接加载的，完全不需要任何额外配置。而《王国之泪》会卡在加载界面，怎么都过不去。解决方法是，安装 TOTKYuzuFix.zip 这个 MOD。如果不知道如何安装 MOD，请先阅读《Switch游戏模拟指南》。

然后就能进游戏了，基本上都能稳定帧率玩，没有什么恶性 BUG 或者严重掉帧。

解决马赛克云

开始玩游戏，大家就能注意到一个比较讨厌的问题。空岛的云彩像马赛克/二维码一样，非常出戏。问题原因在于 Vulkan 着色器（Shader）编译不及时。解决方法有两个：

1. （推荐）重启 Yuzu 再进游戏，效果就正常了。
2. 去网上下载别人的着色器缓存。这样比自己运行时编译着色器缓存会流畅很多。

安装 2K/4K+60FPS MOD

王国之泪的画面在开放世界会非常的糊，甚至比前作《旷野之息》还要糊。这是因为受限制于 Switch 羸弱的性能，游戏内部分辨率实际上只有560p～680p，通过 FSR 超分辨率拉成720p/1080p，自然看起来比原生的 720p/1080p游戏糊。如果用模拟器的 2x 分辨率，则是用 FSR 再超分辨率成 2K/4K，依旧很糊。

而安装 2K/4K+60FPS MOD 之后，我们可以让游戏以原生 2K/4K 渲染，并且大幅提升帧率，提升游戏体验。以下是放大后的效果对比：

下载 MOD 文件：

• 王国之泪 1.2.0 版本 4K+60FPS MOD 下载
• 王国之泪 1.2.0 版本 2K+60FPS MOD 下载
• 王国之泪 1.1.0 版本 4K+60FPS MOD 下载
• 王国之泪 1.1.0 版本 2K+60FPS MOD 下载

如果不知道如何安装 MOD，请阅读《Switch游戏模拟指南》。

安装后，配置游戏（右键菜单->属性）。有以下几个要点：

• 附加项（Add-ons）
  • 勾选所有安装的 MOD
• 系统（System）
  • 启用不安全的内存布局扩展，这样就能使用 8GB 内存，渲染更多细节
• 图形（Graphics）
  • 画面分辨率设置为 1X，使用原生真 4K，而非超分辨率的假 4K
  • 抗锯齿方式设置为无，可以提升性能（可选）

保存后重新进入游戏，便能够以原生 2K/4K+60FPS 运行。如果用的是中端显卡，可能不会跑满 60FPS，但是 50FPS 左右的游戏体验提升也是巨大的。

OpenAI 的 ChatGPT 开放测试引发了新一波的 AI 热潮。首先 ChatGPT 3.5 在对话能力上达到了令人惊艳的水平。其次，有上亿人通过不同方式亲自体验了这一服务。（即使不对中国用户开放，仍然有数百万人通过 VPN 或代理用上了）

在国外，有 Google 赶鸭子上架的 Bard（上架当天股价暴跌 8%），有 Facebook 被迫开源的 LLaMA（不知道被谁给泄漏了源码）。在国内，百度的文心一言已经开过发布会，阿里的通义千问刚刚开始邀请测试。各家互联网公司都在烧钱搞大语言模型，盈利前景尚不明朗，唯有 NVIDIA 老黄赚的盆满钵满。

在坊间，AI 已经被过度神化，主流媒体甚至也在鼓噪“你的工作会被 AI 取代”这种论调。但是对于科技从业者而言，我们需要冷静看待，AI 大语言模型仍然有很大的局限性。它还远不能取代人，甚至不能取代同为程序的搜索引擎。但是不可否认，就像现在每个人都要使用计算机和手机一样，未来每个人都要使用 AI 做一些事情。了解和接触大语言模型还是很有必要的。

TL;DR

• OpenAI 的 GPT-4，还没上手。
• OpenAI 的 ChatGPT 3.5，综合表现在我上手的里面最好。
• 清华大学的 ChatGLM-6B，基本的中英文对话还行，不能处理复杂逻辑问题，编程能力较差。
• Google 的 Bard，英文对话接近 ChatGPT 3.5，编程能力较差。
• Facebook 的 LLaMA，用了但是无法评判。公司自建服务器效果很糟糕，可能不是 65B 完整版。
• 百度的文心一言，还没上手。在 waiting list 等。但还是给李彦宏点赞，敢吃螃蟹，开放测试。
• 阿里云的通义千问，还没上手。只对特定的企业用户和媒体开放，这格局真的不敢恭维。

开放程度对比

• LLaMA 开源，代码和模型都开放下载。虽然用 PC 游戏显卡就能跑，但效果属实不理想，无法称之为对话，更像是鸡同鸭讲。
• ChatGLM 开源，代码和模型都开放下载。清华大学开发，支持中英双语。唯一一个由非商业公司开发的模型。有基本的对话能力，但是由于参数规模较小，还是比 ChatGPT 3.5 弱很多，尤其是在逻辑，编程，多模态等方面。
• ChatGPT 3.5/GPT4 闭源，公开测试。中国用户需要 VPN + 外国手机号，或者使用一些代理服务。
• Bard 闭源，通过 waiting list 加入测试。中国用户只需要 VPN，不需要外国手机号。等待大概半天就能进入。
• 文心一言闭源，通过 waiting list 加入测试。这个等待时间就比较长了，少则一天，多则几天。
• 通义千问闭源，通过邀请码加入测试。有测试资格的人极少。阿里巴巴员工目前也不能内测最新版。

功能体验对比

英文对话能力

GPT-4 还没有上手过，未知。据其他人的测试结果，GPT-4 相比 ChatGPT 3.5 增强了一些悖论和数理逻辑的能力，同时强化了伦理道德约束。

ChatGPT 3.5 算是一个基准标杆。

Bard 在英文对话能力上接近 ChatGPT 3.5。

LLaMA 对话能力比较差，经常不能理解问题。

文心一言，还没上手。

通义千问，内测版差强人意，最新版还未上手。

中文对话能力

GPT-4 还没有上手过，未知。

ChatGPT 3.5 算是一个基准标杆。

LLaMA 对话能力比较差，经常不能理解问题。

文心一言，还没上手。

通义千问，内测版差强人意，最新版还未上手。

LLaMA 中文对话能力极其有限，经常胡言乱语。

Bard 目前完全不支持中文。

多模态生成能力

GPT4 能生成代码，图片（基于 OpenAI 自有的技术 DALL·E 2），甚至还能做简单的网页。可以说是目前最强的。

ChatGPT 3.5 能生成代码。

文心一言能生成代码和图片。图片生成基于开源的 Stable Diffusion, 缺点是单纯通过文字 prompt 很难获得比较高质量的图片。Stable Diffusion 最擅长的还是各种第三方模型，LoRA，ControlNet 以及 image-to-image 等组合使用获取高质量图片。然而这些并不能在文心一言中使用。另外 Stable Diffusion 只支持英文输入，文心一言内部是通过将中文翻译成英文实现的，可能会生成完全不相关的图片。（比如总线变公交车）

Bard，ChatGLM 和通义千问目前只能输出文字和代码。

LLaMA 似乎只能进行文字对话，无法输出代码能复杂内容。

图形编程能力

大语言模型很擅长给出各种算法的代码，但是图形编程能力依然很差。我测了一个很简单的编程问题：用 HTML 和 CSS 画一个红十字/create a red cross with HTML and CSS。

ChatGPT 3.5 的回答，错了一半，是十字但是颜色是反的：

<div class="red-cross"></div>

.red-cross {
  width: 50px;
  height: 50px;
  background-color: #f00;
  position: relative;
}

.red-cross::before,
.red-cross::after {
  content: "";
  width: 25px;
  height: 5px;
  background-color: #fff;
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

.red-cross::before {
  transform: translate(-50%, -50%) rotate(45deg);
}

.red-cross::after {
  transform: translate(-50%, -50%) rotate(-45deg);
}

Bard 的回答完全错误，形状都不对：

<div class="red-cross">
  <div class="cross-bar"></div>
  <div class="cross-bar"></div>
</div>

.red-cross {
  width: 100px;
  height: 100px;
  background-color: red;
  border-radius: 50%;
}

.cross-bar {
  width: 50px;
  height: 100px;
  position: absolute;
  top: 0;
  left: 25px;
  background-color: white;
  border-radius: 50%;
}

ChatGLM 的回答也完全错误：

<div class="cross"></div>

.cross {
width: 20px;
height: 20px;
background-color: red;
position: relative;
margin-right: 10px;
}

.cross:before,
.cross:after {
content: "";
position: absolute;
right: 0;
bottom: 0;
width: 10px;
height: 20px;
background-color: red;
border-radius: 50% 50% 0 0;
transform: rotate(-45deg);
}

.cross:after {
right: 10px;
}

当前的局限性

不擅长细分领域的事实性问题

著名华裔科幻作家姜峯楠对此有一个很著名的论断——ChatGPT 就是给万维网（Web）拍了一张很糊的 JPEG 照片。这指出了 ChatGPT 最核心的弱点：它有海量数据，却无法理解深层的联系，容易产生错误的理解；它很能说会道，却不知道自己在说什么，经常编造看似可信的答案。

我想到了中国社会上行走了上千年的江湖骗子。他们没有真才实学，却不论说什么都能头头是道。大语言模型和江湖骗子具有非常多的相似之处。

很多江湖骗子家里满满一书架的书，但都是浅尝辄止并没有深入研究，行走江湖全靠经验阅历。大预言模型也是一样，虽然被喂了大量的数据，但是它阅读理解的效率极低，只有最常见的知识能够训练的比较好。一旦被问及细分领域的问题，由于训练样本不足，它很容易搞不清楚领域的边界。

首先，我们问一个简单的开放性问题：推荐一些漫画？

1. 《进击的巨人》（Attack on Titan）：讲述了人类与巨人之间的战斗，揭示了一个充满阴谋和秘密的世界。
2. 《海贼王》（One Piece）：讲述了主角路飞和他的伙伴们在寻找传说中的宝藏时的冒险故事。
3. 《火影忍者》（Naruto）：讲述了主角漩涡鸣人成为忍者，并成为村庄英雄的故事，充满战斗、友情、爱情和成长的元素。
4. 《银魂》（Gintama）：以幽默搞笑的方式讲述了一个充满科幻元素的江户时代，主角坂田银时和他的伙伴们经历了种种奇怪的事件。
5. 《攻壳机动队》（Ghost in the Shell）：讲述了一个宏大的未来世界和以及人类与机器之间的融合，主角草薙素子是一个拥有高超能力的狙击手。
6. 《名侦探柯南》（Detective Conan）：讲述了高中生侦探小兰和他的朋友变成了童话样子后，以侦破各种案件为题材的故事。
7. 《鬼灭之刃》（Demon Slayer）：讲述了主人公炭治郎为了报仇，踏上了消灭鬼族的旅程。 8.《妖狐×僕SS》（Inu × Boku SS）：讲述了一个拥有异能的贵族少女和她的护卫之间的故事，充满了奇幻和浪漫的因素。
8. 《约定的梦幻岛》（Promised Neverland）：讲述了一群孤儿在追求自由的过程中，发现了惊人的真相。充满了惊悚和悬疑的元素。
9. 《你好，旧时光》：讲述了一个年轻人回到了过去，重新度过青春期的故事，充满了温情和成长的元素。

ChatGPT 3.5

从整体看，这个回答貌似不错，推荐的都是知名作品。细看能发现一些明显的事实性错误，“高中深侦探小兰”是什么鬼！

下一个问题我们再把领域收窄：火影忍者中有哪些主要角色？

1. うずまきナルト (Uzumaki Naruto)：故事的主角，一名忍者，是四代目火影的儿子，拥有九尾妖狐的力量，梦想是成为火影，得到全村人的认可。
2. うちはサスケ (Uchiha Sasuke)：另一名主角，是宇智波一族的后代，对于家族被灭的仇恨深重，梦想是报仇雪恨，但在成长过程中逐渐变得理性冷静。
3. 春野サクラ (Haruno Sakura)：女主角之一，是一名医疗忍者，对于同班同学的爱慕之情逐渐转变为对于团队和保护村子的责任感。
4. はたけカカシ (Hatake Kakashi)：火影之一，是一名传说中的忍者，拥有众多技能和能力，作为三人小队的领队，传授了许多技能给三位主角。
5. 獣神サスケ (Jūgo Sasuke)：一名受到实验变异的忍者，曾经是八尾人柱力的宿主，后成为守护叶村的一员。
6. 日向ヒナタ (Hyuga Hinata)：女主角之一，是一名拥有白眼的忍者，天生有着强大的能力，曾经对于同班同学的爱慕之情逐渐转变为对于团队的责任感。
7. 綱手 (Tsunade)：火影之一，是一名医疗忍者和扑克大师，曾经是三人小队的领队，拥有强大的能力和技能。

ChatGPT 3.5

如果只看前四行回答，是非常不错的。但是后三行回答都有明显的事实性错误：重吾的名字写错了，他也不是八尾人柱力；雏田的描述和春野樱完全重复；纲手缝赌必输，完全算不上扑克大师。总体来看，回答仍然在火影忍者的领域内。

下面我们继续收缩领域：火影忍者晓组织的成员有哪些？

1. 佐助 (Uchiha Sasuke)：在某些情况下，佐助曾是晓组织的一员。
2. 蝎 (Sasori)：拥有木偶的能力，曾经是晓组织的高级成员。
3. 大蛇丸 (Orochimaru)：曾经是晓组织的创始人之一，拥有着强大的血继限界能力。
4. 鬼鲛 (Kisame Hoshigaki)：拥有着一身鲨鱼样的外表，是晓组织的高级成员之一。
5. 雏田 (Karin)：拥有着特殊的医疗能力，是晓组织的成员之一。
6. 夕日红 (Yūra)：是一个熟练的忍者医生，曾经是晓组织的成员。
7. 御手洗红豆 (Guren)：是晓组织的成员，拥有着控制水晶的能力。
8. 草轮梦蝶 (Tsurugi Misumi)：是晓组织的成员，拥有伸缩自如的身体。
9. 土之器 (Tsuchi Kin)：是晓组织的成员，拥有使用声音的能力。

ChatGPT 3.5

可以看到，GPT 回答的错误比例进一步增大到 2/3。当你问的问题越细，GPT 能依靠的数据样本就越少，理解错误就越多。

大语言模型依然很昂贵

OpenAI 据称训练一次 ChatGPT 要耗费数百万美元，每日运营成本也高达十万美元。大语言模型仍然需要大量算力，而核心硬件 GPU/TPU 已经没有了摩尔定律加持。过去十年 GPU 的算力/美元提升了4倍，但是未来十年这样的事情不太可能重演：芯片工艺遭遇物理瓶颈，中美科技战导致供应链成本上升，芯片可能会越来越贵，越来越缺。如果软件算法没有革命性突破，大语言模型将一直是个烧钱的游戏，只有巨头能玩的游戏。另一方面，训练所需的海量数据也需要钱，甚至有钱都不一定能够买到。大语言模型一开始就高筑围墙，可能会进一步加强科技巨头的垄断地位。

现在 OpenAI 也推出了付费的 GPT Plus 服务，20 美元/月。（同时 API 接口还要额外收费）是不是像极了凭几句不靠谱的话术就能赚钱的江湖骗子？现实中也有听风水大师买股票，喝中药汤治疗癌症的。GPT 起码还有一些道德约束，不会给你投资建议或者健康建议。

如果说 OpenAI 这种初创公司烧不起钱还能理解。现在连微软也烧不起了，要给 New Bing 的聊天功能加广告了。这些成本最终还是会转嫁到消费者身上。

标准

这里定义的前端构建工具需要符合以下条件：

• 能够构建生产用的前端资源。
• 提供带 HMR 的 Dev Server。
• 支持常见的前端技术，比如 Sass, LESS, CSS modules, code splitting。
• 支持插件扩展。
• 不限于某种 UI 框架，不捆绑不必要的运行时内容，比如 Redux。（排除 UMI 之类的深度定制框架）

生产可用

这里定义的生产可用条件：

• 流行度高。(npm 周下载量 >100k)
• 维护活跃。(六个月内至少发布了一个版本。)
• 没有严重的性能或兼容性问题。

Vite 4

Vite 基于 esbuild (用 Go 语言编写) 和 Rollup。它采用了 Unbundled Dev Server 模式，通过浏览器原生 ESM 特性，省去了 Bundle 步骤，以达到比 Webpack Dev Server 更快的 HMR 和启动速度。Vite 4 提供了一个新的基于 SWC 的 React 插件 @vitejs/plugin-react-swc ，用于替换旧的基于 Babel 的插件。这让 React Fast Refresh 的速度快了 20 倍。目前，Vite 仍然是速度最快的前端构建解决方案之一。

Vite 易于使用。即使不进行任何配置，也能开始使用。如果需要定制，它的文档也非常详细好用。Vite 兼容 Rollup 插件和配置接口，甚至可以借用 Rollup 的文档。用户更容易找到需要的插件，遇到问题也更容易找到解决方案。编写 Vite 插件也相对容易。所以 Vite 的社群和生态系统成长很快。Vite 的 JS API 设计简单清晰，功能丰富。基于 Vite 开发你自己的构建工具很容易。

Parcel 2

Parcel 2 基于一系列用 Rust 重写的高性能模块，比如 SWC 和 Parcel CSS，实现了优于 Webpack 的性能。默认配置下，Parcel 2 的性能介于 Vite 4 和 Webpack 5 之间。但是可以通过启用一些实验性功能提升性能，比如 swc 压缩。

Parcel 2 的另外一个特点是开箱即用。它的默认配置已经涵盖了 TypeScript，CSS modules，JSX，React Fast Refresh，图片压缩，SVG 优化等特性支持。另外，当检测到 Sass 或 LESS 时，Parcel 2 会自动帮你安装需要的依赖包。对于常规的前端应用，你完全不需要配置文件。

Parcel 有自己独特的架构和接口设计，这让它几乎不可能直接借用 Webpack 和 Rollup 的插件。因此它的生态系统中第三方插件很少。另外，由于 Parcel 发布大版本的频率很低，内置插件为了避免 Breaking Change 而很难升级，比如 MDX 2.0 至今没有被支持。这可能是 Parcel 2 最大的劣势。

Webpack 5

Webpack 依然是最流行的选择，有最完善的特性，以及最大的生态系统。

Webpack 很慢，但是你可以用一些 loader 和插件替换默认组件来提速：

• swc-loader
• swc-minify-webpack-plugin

观察列表

一些还处于早期阶段的有潜力项目。

Rspack

用 Rust 写的 Webpack 替代品，由字节跳动创建。虽然还处于早期阶段，但是已经表现出比 Vite 更快的构建速度。同时兼容 Webpack 插件，可扩展性很强。

未入选

Turbopack

为 Next.js 框架设计的高性能构建工具，原生支持 SSR。未入选原因是因为目前只能用于 Next.js 框架。

UMI

蚂蚁集团的构建工具。未入选原因是因为过度定制化，只支持 React，内置了过多 Redux 之类的运行时。

ICE

阿里巴巴的构建工具。未入选原因是因为过度定制化，只支持 React，内置了过多 Redux 之类的运行时。

Create React App

React 官方的构建工具。未入选的原因是因为过度定制化，只支持 React，不支持配置和插件。

性能测试

	dev server cold start	dev server warm start	production build
rspack 0.1.1	2.2s	2.0s	1.4s
vite 4.2.1	4.3s	1.3s	6.5s
parcel 2.8.3	13.0s	1.3s	15.7s
webpack 5.76.2	14.2s	14.2s	15.8s

详情参见 https://github.com/guoyunhe/front-end-builder-benchmark

技术趋势

一些可能会让前端构建工具更快更好的技术。

原生 Node.js 模块与 WASM 模块

用 Rust，Go 等语言编写的 Node.js 模块，其性能与产物格式有很大的关系。不考虑多线程的情况，从高到低分别是 Native > WASM > JS。JS 和 WASM 本身都是单线程的，除非使用 Cluster 模式（目前还没有在前端构建工具上比较成功的）。支持多线程的 Native 模块，性能会更强，esbuild 就是一个例子。

但是，原生模块必须为不同的平台预编译对应的二进制文件，不如 WASM 或 JS 的“一次编译，到处运行”方便。

在实践中，原生模块通常用于核心高负载模块，比如 rspack，swc，esbuild。而插件还是广泛采用 JS。WASM 仍然比较少见，一个例子是 swc 的插件开发。

从 Unbundled 回到 Bundled？

用 JS 写的 Webpack Dev Server 采用 Bundled 模式启动。即先由 Webpack 将多个源码文件打包成一个，再传输给浏览器。在浏览器的网络记录中，你只会看到几个网络请求。因为 Webpack 打包的效率低，启动速度很慢，热加载也很慢。

后来出来了 Snowpack （已废弃），可能是第一个 Unbundled 模式的 Dev Server。采用 Unbundled 模式启动 Dev Server，通过原生 ESM 加载，省去了 Bundle 的过程，提高了启动速度。当 Dev Server 启动时，不会进行编译，而是在接到浏览器请求时，动态编译每个文件，每次传输一个源文件对应的代码。过程大致是：

请求 → 编译 → 响应 → 请求 → 编译 → 响应 → … → 请求 → 编译 → 响应

这导致 Snowpack 的启动速度极其缓慢，对比 Webpack Dev Server 并没有显著优势。

后来 Vite 继承并改进了 Snowpack 的思路。它将 node_modules 中大量的依赖用 esbuild 先 Bundle 成单个文件，而项目源码依旧采用 Unbundled 模式。得益于 esbuild 的强大性能，不管是依赖的 Bundle，还是单个源码文件的转译，都非常快。因此 Vite 对比 Webpack Dev Server 取得了巨大的性能优势。

然而，随着项目体积增大，需要加载的 ESM 模块越来越多，Vite 的启动速度会变慢。假设项目的 src 中有 1000 个 JS/TS 文件，就会有 1000 个 HTTP 请求。现代的浏览器只允许每个服务器建立 6 个连接，也就是说最多只能并发 6 个 HTTP 请求，导致阻塞。

因此 Parcel 2，Turbopack 和 Rspack 选择了回到 Webpack Dev Server 的 Bundled 模式，通过用 Rust 重写关键部件，改进打包和编译性能来提高性能。

但是根据 Turbopack 的 Benchmark，只有在 src 中有 1000 个以上的 React 组件时，Turbopack 对比 Vite 才会有比较明显的优势。但实际应用中，1000 个组件（约100K到1M行代码）已经是相当大规模的应用了。而 Vite 的冷启动速度仍然可以接受：4.2s。另外，我觉得这个 Benchmark 用 Turobopack 的 Server Side Rendering 对比 Vite 的 Client Side Rendering，并不公平，因为 Vite 也是支持 Server Side Rendering 的。

总结一下，我觉得 Vite 的 Unbundled 策略和 Parcel 等的 Bundled 策略各有所长，在实际应用中并不能拉开明显的性能差距，未来很长一段时间仍然会共存，而不是此消彼长。

更快的 Sass 编译器

Sass 的老编译器 node-sass 已经被官方废弃，不再维护。新的官方编译器 Dart Sass 令人迷惑：

• 原生构建二进制程序没有 Node.js 接口，无法集成到现有的 Node.js 工具中。除非你用 Node.js 的 exec 函数执行。(不推荐在生产中这样做)
• JavaScript 构建要比 node-sass 慢 4 到 30 倍 (取决于项目大小)。如果你的构建工具调用 Sass 接口的方式不正确，速度甚至会更慢。详见 Issue #1557 和 #1534。

对于大量使用 Sass 的生产项目，这肯定是不可接受的。很多项目选择继续使用废弃的 node-sass 编译器。

现在已经有人在开发用 Rust 重写的 Sass 编译器：

• grass。只提供编译成 WASM 的版本，但是性能并不好。
• rsass。可惜，这个项目也没支持 Node.js API，也无法直接用于现在的前端构建工具生态。

更快的 TypeScript 检查器

TypeScript 很慢，因为它完全是 JavaScript 写的。幸运的是，我们通常不需要在构建前端项目的时候检查类型。Babel, esbuild 或 swc 会直接忽略所有类型。但是，如果你项目有很严格的 QA 要求，你不得不运行 tsc 命令检查类型，CI 工作流就会被拖慢，即使对于小型项目 (10k lines) 或中型项目 (100k lines) 也很明显。

于是乎，重写 TypeScript 检查器的呼声越来越高。我们已经能看到一些这方面的尝试：

• stc, 由 swc 的作者创建。已经可以试用。
• deno, Node.js 的替代项目，提出了原生支持 TypeScript 的计划。

经过我个人测试，大部分 Switch 游戏都能在 PC 上流畅运行。偶有崩溃的情形，但是频率不高。

模拟器

目前最流行的是 yuzu 和 Ryujinx, 两者模拟效果差不多，yuzu 有中文翻译。我这里选了 yuzu。

硬件要求

1. CPU：五年内的主流 x86_64 CPU 应该都没问题，推荐四核心以上。我用的 AMD 5600X。
2. GPU：需要 GTX 1060 及以上水平的显卡才能流畅运行。我的 AMD RX 6700 可以跑两倍分辨率。
3. 手机 SOC：Android 需要骁龙 8+ 以上的 SOC 才能流畅运行马里奥赛车之类的游戏。
4. 手柄：通用的双摇杆手柄就行。

系统要求

目前仅支持 Windows, Linux 和 Android，苹果用户暂时没有办法玩了。

安装模拟器

官方下载连接

Linux 用户有几种选择：

1. 从官网下载 AppImage 包 https://yuzu-emu.org/downloads/
2. 从 Flathub 安装 https://flathub.org/apps/details/org.yuzu_emu.yuzu
3. 在你发行版的 OBS, AUR, PPA 找一找有没有打包好的

安装好，运行应该是这样子的：

如果启动后界面是英文的，从菜单栏选择 Emulation –> Configure… –> General –> UI –> Interface language 修改成中文。

安装Switch系统固件（非必需）

部分游戏没有固件也能运行。但是安装固件可以让更多游戏能玩，减少一些游戏崩溃的概率。《塞尔达：王国之泪》需要 16.0.1 或更新的固件才能运行。

https://archive.org/download/nintendo-switch-global-firmwares

下载固件 zip，一般用最新的。解压后会得到几百个小文件。

打开 yuzu，通过菜单栏 文件 –> 打开 yuzu 文件夹，然后依次打开 nand –> system –> Contents –> registered 文件夹，将之前解压的所有小文件都复制到这里。

安装 prod.keys 和 title.keys

这两个是关键的密钥文件。去网上搜一搜就好了，这里就不提供下载了。

prod.keys 是必需的系统密钥，缺少了 prod.keys 密钥就玩不了游戏。prod.keys 和游戏无关，不管是新游戏还是老游戏，都不用更新 prod.keys。但是 prod.keys 和固件版本相关，比如 14.0 固件的 prod.keys 在 15.0 固件里就用不了。在网上搜索的时候，要带上固件版本号“prod.keys v16.0.0”。

title.keys 不是必需的，只有联机才需要。

打开 yuzu，通过菜单栏 文件 –> 打开 yuzu 文件夹，然后打开 keys 文件夹，将你找到的 prod.keys 和 title.keys 文件都复制到这里。

下载游戏 ROM

最常见的游戏 ROM 有 NSP 和 XCI 两种格式。yuzu 都能识别。下载完 ROM 之后，建议放到一个文件夹下面。

双击 yuzu 窗口中间，选择你的游戏文件夹，yuzu 会自动扫描文件夹里的游戏。

安装更新和 DLC

如果你还下载了游戏更新和 DLC（通常也是 NSP 和 XCI 格式），点击菜单栏的 文件 –> 安装到 NAND, 选择你的更新和 DLC 文件即可安装。

运行游戏

单击游戏即可运行。

差不多就是这样！

安装 MOD

Switch 性能比较差，像塞尔达这样的游戏，只能锁了 30 帧运行。但是在 PC 上模拟，硬件性能不再是问题。通过安装 60FPS 的 MOD, 我们可以玩到比 Switch 更流畅的体验。

首先打开官方 MOD 下载页面，搜索英文“Zelda”，找到对应的游戏。然后下载名为 60FPS 的 MOD。注意：尽量选择 MOD 支持的游戏版本，以免游戏崩溃。

下载完成后，解压文件，得到一个 60FPS 文件夹。

打开 yuzu，在游戏列表中找到塞尔达，右击，选“打开 MOD 数据位置”。

将之前解压得到的 60FPS 文件夹，复制到此处即可。

然后启动塞尔达，就能够以 60FPS 的流畅度玩了！如果有 3080 / 6900 这样的高端显卡，甚至可以2倍缩放画面，实现 4K@60FPS 的体验。

还有很多其他类型的 MOD, 大家可以自行探索。

开发者通常在最新的浏览器上进行开发，以使用最新的 JavaScript 语法，浏览器接口，让工作更有效率，代码质量更高，更不容易过时。

而用户则可能仍然在使用旧版的浏览器。比如，某些政府教育系统仍然在使用 Windows XP，用户能安装的最新的浏览器是 Chrome 49。有些用户可能只是没有升级浏览器的习惯，导致他们的 Chrome 还是 86 版本。

为了平衡两方面，开发者通常会借助一些工具，自动转译语法，并 Polyfill 新的接口，以兼容某个特定版本的旧浏览器。通过语法分析，按需插入 core-js 中的 Polyfill 代码。而 core-js 缺少的部分，可以用 polyfill-service 补全。

ES 语法转译

Optional Chaining 这种比较新的 ES 语法在老版本浏览器无法支持，运行时会报错。

const dogName = adventurer.dog?.name;

为了兼容旧版浏览器，必须在构建过程中就将其转译成 ES5/ES3 语法。

var _adventurer$dog;
const dogName = (_adventurer$dog = adventurer.dog) === null || _adventurer$dog === void 0 ? void 0 : _adventurer$dog.name;

转译功能通常由 babel，swc，esbuild 等 JavaScript 转译工具提供。

ES 特性 Polyfill

Promise，Stream 等特性需要插入特定的 Polyfill 代码。

esbuild 无法自动分析并 Polyfill 特性，只能手动导入。而 swc 和 babel 可以自动分析源码，按需自动导入。swc 和 babel 都是基于 core-js 进行 polyfill。

浏览器特性 Polyfill

core-js 只提供 ES 特性的 Polyfill（准确的说，是浏览器和 Node.js 交集的部分）。但是浏览器除了 ES 标准外，还提供其他浏览器特有的特性，比如 ResizeObserver。这就需要一个补充方案。

方案1是手动取导入 Polyfill 代码，比如在项目中 import 'whatwg-fetch' 就可以支持 fetch() 接口。但是这对开发者而言是一个比较大的负担。

方案2是在页面中引用 polyfill.io 的脚本，服务器会根据 UA 判断需要加载哪些 Polyfill 代码。开发者也可以用 polyfill-service 自建服务器。缺点是增加了一些服务器开销，也会阻塞应用本体脚本的加载，造成一些成本提高和性能损失。

CSS 语法转译

很多 CSS 特性在未成为正式标准之前便已经被浏览器支持了。但是在这个成为标准的过程中，CSS 特性的提案可能会修改。浏览器厂商为了防止自己目前的实现与之后的正式标准冲突，会在选择器和属性名之前，加上自己的前缀，Firefox 是 -moz-，Chrome 和 Safari 是 -webkit-，而 IE 是 -ms-。

比如下面这段代码：

:fullscreen {
}

为了兼容不同的浏览器，尤其是老浏览器，需要转译成：

:-webkit-full-screen {
}
:-ms-fullscreen {
}
:fullscreen {
}

转译过程主要通过 postcss 实现。当前流行的前端应用构建工具，比如 create-react-app, vite, parcel, 都集成了 postcss。

横向对比

	babel	esbuild	swc	polyfill service	postcss
ES 语法转译	✅	✅	✅
ES 特性 Polyfill	✅		✅	✅
浏览器特性 Polyfill				✅
CSS 语法转译					✅

总结

综合来看，目前没有一种技术能够单独达成全自动的浏览器兼容性。建议使用 babel + polyfill service + postcss 之类的融合方案。

当使用一种新特性时，可以先查一下 caniuse.com 支持的浏览器版本。如果需要 Polyfill，要看自己选用的 Polyfill 方案（core-js，polyfill-service）是否支持。如果不支持，则需要手动 Polyfill 这个特性。

实践

Create React App

以 create-react-app 项目为例。首先我们需要配置项目支持的浏览器版本，让底层的 babel 和 postcss 将 JS 和 CSS 转译到目标浏览器支持的语法，并尽可能注入所需的 Polyfill 代码：

{
  "browserslist": {
    "production": [
      "chrome > 49",
      "firefox > 53",
      "ie 11"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

然后，我们需要修改 HTML 模板，注入 Polyfill.io 的脚本，以支持额外的 Polyfill 特性：

<!DOCTYPE html>
<html lang="en">
  <head>
    <script src="https://polyfill.io/v3/polyfill.min.js"></script>
  </head>
  <body>
    ...
  </body>
</html>

Vite

Vite 默认只支持 Chrome 87+，这个要求对大部分实际应用可能太过苛刻。如果要支持更早的浏览器，则必须使用 legacy 插件：

import react from '@vitejs/plugin-react';
import legacy from '@vitejs/plugin-legacy';
import { defineConfig } from 'vite';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    react(),
    legacy({
      targets: [
        "chrome > 49",
        "firefox > 53",
        "ie 11"
      ],
    }),
  ],
});

然后，我们需要修改 HTML 模板，注入 Polyfill.io 的脚本，以支持额外的 Polyfill 特性：

<!DOCTYPE html>
<html lang="en">
  <head>
    <script src="https://polyfill.io/v3/polyfill.min.js"></script>
  </head>
  <body>
    ...
  </body>
</html>

最近找工作接触过的一些深圳外企。

Artflow AI（远程）

职位：全栈。

来源：猎头。

流程：

• HR 直接拉了一个群，初创公司，CEO 和 CTO 都是华人。
• 技术笔试，做一个全栈 demo, 重视单元测试。
• 技术面试，中文，两个面试官分别是 CTO （算法/架构）和全栈开发。问的都是一些实际项目的问题，没有很偏门很细节的问题。
• 综合面试，英文，两个面试官分别是 CEO 和另外一个 Co-Founder。主要问项目经历，以及对这个公司做的产品有什么想法和建议。
• 谈薪资待遇（最后没谈拢）。

优点：

• 不用八股文，不用刷题。
• 流程很快，从递简历到拿 offer 一周时间。
• 全员远程，灵活办公。
• 可以谈 14 薪，比 16 薪或 18 薪要保险一点。

缺点：

• 试用期三个月，发正式工资的 80%。
• 公积金 7%。
• 因为时差的原因，开会时间是中国的晚上 9 点到 11 点。

SkyScanner

职位：全栈。

来源：LinkedIn。

流程：

• HR 电话。
• 待续。

亚马逊 AWS

职位：前端架构（偏全栈）。

来源：LinkedIn。

流程：

• HR 电话，没啥特别的。
• 技术面试1，主要是介绍自己做过的项目，不会问技术细节问题。
• 技术笔试，做一个全栈的系统 demo （技术栈不限）。要用到至少一种 AWS 服务，最常用的是 S3，要实际部署到 AWS 上运行，还要写系统架构设计报告，比较耗时。我觉得他们的岗位描述有问题，笔试全是全栈+运维的东西，前端的比例很少。
• 技术面试2，要求做 PPT 介绍笔试题目的系统设计。我到这一步就被通知招聘冻结了，没有后续了。

优点：

• 不用八股文。
• 不用刷题。
• 薪资水平在外企中算高的。

缺点：

• 做 demo 比较耗时，前后搞了一周的时间。主要是 AWS 比较难搞，之前的工作都是有专门的运维搞AWS, 开发是不会直接去操作的。
• 突然终止招聘不太靠谱啊，可能很长一段时间都没岗位了。
• 开发也要求走客户，出差可能会比较多。

Flexport

职位：全栈。

来源：公司官网。

流程：

• HR 电话，聊完之后说安排面试但又没有后续了。

缺点：

• HR 不靠谱。
• 薪资的现金部分比阿里低，期权妥妥的废纸。

Nike

职位：全栈。

来源：脉脉。

流程：

• HR 面试，有英文口语部分。
• 技术笔试，做一个全栈 demo, 技术栈不限，重点要求单元测试和 CI （GitLab）。
• 技术面试，有英文口语部分，不涉及笔试 demo 的内容，也没有问技术细节，主要介绍项目经历和个人发展的问题。
• HR 沟通职级和薪资，因为降薪太多，就没继续了。

优点：

• 不用八股文。
• 不用刷题。
• 面试过程比较轻松友好。

缺点：

• 薪资比较低。
• 要对接 Nike 收购的数据公司，可能要处理一堆技术债务。

避坑

• 国内小厂：不要相信小而美。
• 假外企，假国企：都是大厂出来的，比大厂还能卷。

总结

我个人是比较喜欢偏实践的面试/笔试的，毕竟啥 service worker 啥 event loop 的技术细节，工作中也是随用随搜，工作中 99% 用不到。面试的大部分都是全栈或者前端偏全栈，在做 demo 的过程中我会尝试一些新的技术，比如 Vitest, Adonis, 还是很有收获的，比每天上班重复那一套东西要有趣。

技术上，纯前端不多，大部分是全栈。前端 React 还是比较通吃，有些公司用 Vue，不建议学 Angular 了。后端 Node.js, Python, Java 比较多，但是面试很多不限制编程语言，可以后面再转。除了基本的功能实现，单元测试基本上每家都会考一下。另外 CI, 云服务，也是常会遇到的。笔试考 demo 的好处是可以边做边学，不用事先背一大堆可能用不到的东西。

外企的薪资普遍比较低。薪资高的要么是亚马逊这样的大厂，要么是搞区块链的不差韭菜。阿里的开发 P6 英文叫 Software Engineer II, 对应到其他外企同级别的岗位一般也叫这个，再上面是 Senior Software Engineer 和 Lead Software Engineer。但是普通外企的 Software Engineer II 的年薪也就是阿里开发 P5 的水平，甚至 Nike 这种 Senior Software Engineer 也给不到阿里 P6 的水平。

但是另一方面，大部分外企的评价体系决定了他们是真的闲。有项目就做项目，没项目就自行安排。不会像国内大厂一样，盲目上项目堆人力，做十个烂九个。开会没完没了，对接数不清的人。国内大厂的小领导们，带着下属疯狂卷影响力，对公司业务和个人成长基本是负作用。这种又累又绝望的感觉，让我觉得工资低一些的外企也变香了。

继续找。

2022 年，Webpack + Babel + Terser 仍然是前端项目构建工具的主流，广泛用于各种生产环境。不可否认，Webpack 和 Babel 仍然在持续进化，对各类研发提供了最稳定且全面的支持。但是随着前端项目规模的增长，CI 流水线的普及，构建性能问题已经成为了影响开发效率的一个关键因素。下一代构建工具，试图从不同的角度实现对构建效率的提升。

esbuild

用 Go 语言实现的构建工具，提供了编译，打包，压缩能力。由于是原生程序，且几乎不依赖第三方库，充分利用 CPU 多核架构等原因，esbuild 实现了夸张的毫秒级编译速度，效率数百倍于 Webpack + Babel。

优点：

• 高性能。目前最快的实现，整体上略优于 swc。
• 低占用。Go 语言对字符串的内存优化很好，即使采用多线程工作方式，内存占用仍然远低于基于 Webpack 的工具。

缺点：

• 自身不提供 HMR，需要依赖其他工具实现。
• 不支持 React Refresh，对 React 的 HMR 不能用 webpack-dev-server + esbuild 编译的方案。
• 产物代码分割功能仍处在实验阶段，相比 Webpack 和 Rollup 还是比较简单，不太可靠。
• 插件生态不健全。

适用场景：

• 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
• Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
• Jest 和 SSR 等 Node 运行环境的代码转译。
• 嵌入其他构建工具。比如 Vite 用了 esbuild 的编译和压缩能力，不足的部分用 Rollup 插件体系和自己实现的 HMR 补全。

swc

用 Rust 语言实现的构建工具，swc 实现了编译和压缩能力，swcpack 实现了打包能力（实验性）。swc 设计之初就是完全对标 Babel 的，相比 esbuild 拥有更广泛的适用场景。

优点：

• 高性能。实际测试略慢于 esbuild，但也比 webpack+babel+terser 快上几十倍。
• 支持 React Refresh。这一点是对 esbuild 的巨大优势，且短期内 esbuild 无法克服的问题。

缺点：

• 自身不提供 HMR，需要依赖其他工具实现。
• 打包能力还是实验性质，缺乏高级配置支持。
• 插件生态不健全，用 Rust 编写插件门槛较高。

适用场景：

• 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
• Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
• Jest (@swc/jest) 和 SSR 等 Node 运行环境的代码转译。
• 嵌入其他构建工具。比如 Parcel 用了 swc 的编译和压缩能力，不足的部分用自己实现的 HMR 补全，并有 Parcel 自己的插件体系。

Vite

基于 esbuild 的编译和压缩能力，Bundleless 的 HMR 实现，并用 Rollup 插件生态补足了常用的打包特性。目前性能和特性综合考量的最佳选择。

更早的 Bundleless 实现 Snowpack 已经泯然众人了。Bundleless 最大的问题在于，现在前端应用的依赖树太深太广，模块文件太多，逐个文件加载导致启动速度极其缓慢。而 Vite 则是融合了 Bundle 和 Bundleless 两种策略，对 node_modules 还是用 esbuild 去快速 bundle，一次性加载，对于源码再采用 bundleless 策略。这样就平衡了启动速度和热加载速度。

优点：

• 构建速度更快
• 热更新速度更快
• 能够使用众多的 Rollup 插件

缺点：

• 由于 esbuild 不支持 React Refresh，React 项目还是要走 Babel，一定程度上拖慢了速度。
• Rollup 及其插件生态还是以 JS 为主，性能优化空间有限。Vite 作者寄希望于 esbuild 打包能力和插件生态成熟，用 esbuild 替换掉 Rollup。

适用场景：

• Web 前端应用
• 浏览器插件
• Electron 应用
• 小程序

Parcel 2

Parcel 基于 swc 并有自己的 HMR 和插件生态。设计上与 Vite 类似，但 Parcel 自研部分更多，而 Vite 依赖且受限于 Rollup。性能上 Parcel 甚至更快一些，尤其是缓存性能，热启动极快。但在稳定性上 Parcel 控制的并不好，一个最简单的 React 应用都需要一些 hack 才能工作。

优点：

• 构建速度快
• 缓存效率高
• 热更新速度快

缺点：

• 不兼容 pnpm
• 插件生态不足

适用场景：

• Web 前端应用
• 浏览器插件
• Electron 应用
• 小程序

Turbopack(Alpha)

用 Rust 实现 Webpack 替代，工作原理和 Webpack + Webpack Dev Server 保持一致，而没有走时下流行的 bundleless 路线。当项目源码（不包括 node_modules）文件数量达到数千，Vite 启动速度会随文件数量降低，即使本地几乎不存在网络延迟，数以千计的 HTTP 请求以及代码转译任务仍然耗时不菲。而 Turbopack 则通过提升打包性能，在保持 Webpack 工作方式的情况下，实现了快速启动和 HMR。当前 Turbopack 的测试性能是领先 Vite 的。

假如 Vite/Parcel 也用 Rust/Go 完全重写，那么 Vite/Parcel 和 Turbopack 应该具有以下关系：

• 在文件数量小于 N 时，Vite/Parcel 的冷启动速度更快，但是 Turbopack 也足够快。
• 在文件数量大于 N 时，Turbopack 的冷启动速度更快，且于 Vite/Parcel 的差距越来越大。
• Vite/Parcel 的 HMR 速度总是快于 Turbopack，但是两者都足够快，以至于差异肉眼无法分辨。

可惜 Turbopack 目前并没有推出正式版本，完全没有达到 Vite/Parcel 的成熟度，因此完全没有可比性。目前只能关注，深入分析或评测意义不大。