Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 在接受碎片化与内置引擎之间
2025 年 3 月 — Tauri 试验 Verso
2026 年 7 月的 Verso — 已正式停滞
同一时期的 Servo 本体 — 月度发布列车与 crates.io
LTS 0.1.x — 承诺的内容，以及不属于承诺的部分
那么碎片化问题解决了吗 — 没有，只是算法变了
现在该如何选择 — 判断标准
结语
参考资料

引言 — 在接受碎片化与内置引擎之间

用 Web 技术做桌面应用，长久以来的算术只有两条路。像 Electron 那样把 Chromium 整个内置进应用，所有操作系统上跑的都是同一个引擎，渲染表现一致，代价是每个应用都要背上一份浏览器体积和内存开销。反过来，Tauri 通过 wry 借用操作系统里已经装好的 webview — 按 wry 文档的说法，Linux 上是 WebKitGTK(需要 GTK)，Windows 上是基于 Edge Chromium 的 WebView2，macOS 上是 WKWebView。二进制体积小了，但同一份前端代码要在三个不同的引擎上跑。

这「三个引擎」正是业界所说的 webview 碎片化问题。CSS、JS 特性的支持时间点各引擎不同，更新节奏又绑定在操作系统上各自为政，结果就是三个引擎都得测。Tauri 阵营并非不知道这个问题 — 正因如此，2025 年才出现了基于 Servo 的 webview 项目 Verso 这个实验，本文就是直接依据仓库和注册表记录，核实这项实验截至 2026 年 7 月究竟走到了哪一步。结论先说：Verso 已经正式停止，而 Servo 本体的嵌入反而在这段时间变得更加现实了。

关于 Tauri 2 本身的一般性介绍，已经在Tauri 2 深度解析一篇里讲过；浏览器引擎的格局，也已经在浏览器引擎 2026一篇里讲过，所以这里只聚焦 2025 年以来的变化。

2025 年 3 月 — Tauri 试验 Verso

时间线的起点，是 Tauri 团队在 2025 年 3 月 17 日发布的 Experimental Tauri Verso Integration。要点如下：

Servo 的嵌入 API 过于底层，很多人被复杂的 API 吓退，作者本人也坦承自己曾是其中之一。于是 Verso 在它之上叠加了一层高层 API，Tauri 则通过可替换默认运行时 tauri-runtime-wry 的自定义运行时 tauri-runtime-verso 来接入 Verso。
当时已经跑起来的东西有：tauri-cli 工作流、React + Vite 的 CSS 热重载、官方的 log、opener 插件，以及窗口大小、位置、最大化、最小化、关闭等窗口操作，还有 data-tauri-drag-region 属性。
但文中明确写道，它「功能不如生产环境中已有的后端那样丰富」。

这项工作的资金来源也留有记录。NLnet 的 NGI Assure 基金执行了两笔资助 — Servo Webview for Tauri(2022-08 至 2024-03)和 Servo improvements for Tauri(2024-04 至 2024-08)。也就是说，Verso 并不是一个业余项目，而是靠有截止期限的资助运转的实验 — 这一点正是理解它后来结局的关键。

同一篇博客文章的「future works」部分，有一句话值得留意。作为长期目标，文章提到了一个像 Windows 上的 WebView2 那样、只需系统级安装一次、由多个应用共享的常青(evergreen)版 Verso，并称这样一来「就不用在应用里内置浏览器，能大幅缩小打包体积」。反过来读，这等于是 Tauri 团队自己承认 — 在那种常青版分发方式落地之前，Verso 这条路走的，其实是和 Electron 同一类的「内置引擎」成本。

2026 年 7 月的 Verso — 已正式停滞

接下来看仓库记录。以下所有日期都是直接从 GitHub/GitLab API 与 crates.io 注册表核实所得。

时间点	事件	依据
2024-07-13	开发者 Wu Yu Wei 发表 Verso 0.1 介绍文章	wusyong.github.io
2025-03-13	GitLab 上创建 `verso-browser/verso` 项目 — 开发主阵地迁往 GitLab，GitHub 转为镜像	GitLab API `created_at`
2025-06-17	GitLab `main` 分支的最后一次提交	GitLab commits API
2025-07-10	GitLab 项目的最后一次活动	GitLab API `last_activity_at`
2025-09-27	预编译 `versoview` 的最后一个发行版 v0.0.9(锁定 Servo 提交 19da3bc)	tauri-apps/verso releases
2025-10-03	`tauri-runtime-verso` 的最后一次提交(补充排错文档)	GitHub commits API
2025-10-08	GitHub 镜像上出现归档公告提交(PR #312)，随后仓库被归档	versotile-org/verso

已归档的 GitHub 镜像的 README 公告写得客气又坦诚。大意是 — Verso 目前已不再维护。这个项目原本是想弄清楚，Servo 要成长为一个成熟的浏览器还需要什么，其中不少重要贡献已经并入了 Servo 本体(参见这篇幕后文章，2025-05-13)。但随着 Servo 接连发布重大版本，「受限的人力和资金让项目跟不上这个节奏」，于是暂时把仓库归档，等待重启的机会。

GitLab 那边的 README留下了一句更实际的话 — Verso 仓库自己写道，「就目前而言，Servoshell(Servo 的演示浏览器)大概会带来更好的用户体验」。

还有几个细节值得记一笔。第一，tauri-runtime-verso 从未发布到过 crates.io — README 里的安装方法至今仍是 git 依赖。第二，预编译的 versoview 二进制只覆盖四种目标：x64 Linux/Windows/macOS 和 arm64 macOS，而最后一个版本 0.0.9 锁定的 Servo，是 2025 年 9 月时的提交。也就是说，今天跑这个实验，跑的是一份落后了十个月的 Servo。第三，Tauri 组织的分支仓库 tauri-apps/verso 在 2026 年 5 月 4 日确实有过一次推送，但打开一看，内容只是 CI 日志配色和 GitHub Actions 版本警告的清理 — 不是恢复维护，只是打扫仓库。最后，有一个数字能说明这场迁移给社区留下了什么 — 截至本文写作时(2026-07-17)，已归档的 GitHub 镜像有 5,404 颗星，而成为真正主阵地的 GitLab 项目只有 29 颗星。

同一时期的 Servo 本体 — 月度发布列车与 crates.io

在 Verso 逐渐停摆的同时，Servo 本体发生的却是相反方向的事情。嵌入方式从「克隆仓库、想办法链接」变成了「从注册表拉取」。

2025-10-20，Servo 从 GitHub 发行版 v0.0.1 开始进入月度发布(v0.0.2 于 2025-11、v0.0.3 于 2025-12、v0.0.4 于 2026-01、v0.0.5 于 2026-02、v0.0.6 于 2026-03)。
2026-04-13，官方博客文章 Servo is now available on crates.io 伴随 servo crate 0.1.0 一同登陆 crates.io — 这是 Servo 作为一个库的首个 crates.io 发行版(rc1 于 4 月 4 日发布)。文章明确表示，演示浏览器 servoshell 没有发布到 crates.io 的计划。
此后月度列车照常运行 — 0.2.0(2026-06-05)、0.3.0(2026-06-15)，以及在本文写作前一天，2026-07-16 登陆 crates.io 的 0.4.0(截至写作时，对应的 GitHub 发行说明还没出来 — 这个项目一直有先发布 crate、后补发行说明的习惯)。

这篇博客文章对自己的评价是克制的 — 正如版本号所示，这还不是 1.0，文章也写道「就连 1.0 对 Servo 意味着什么，讨论都还没有结束」。官方的说法是，节节攀升的版本号，体现的是对嵌入 API「日益增长的信心」。

月度更新到底有多密集，可以从最新一篇月度文章 May in Servo(发布于 2026-06-30)中看出 — 0.3.0 装进了 5 月一个月里的 391 次提交(3 月是 534 次)，嵌入 API 相关条目里包括最低支持 Rust 版本从 1.86.0 升到 1.88.0、cookie／偏好设置／诊断 API 方面的工作，以及随 SpiderMonkey 升级到 140.10.1 一并到来的内存安全修复。从嵌入方视角看更重的功能(比如多窗口、代理支持)，从 December in Servo 开始，几乎每篇月度文章都在稳定出现。

LTS 0.1.x — 承诺的内容，以及不属于承诺的部分

看 crates.io 的版本列表，会发现有两个发行版的顺序有点奇怪 — 0.3.0(6 月 15 日)之后出现了 0.1.2(7 月 5 日)。这就是 Servo 的 LTS 分支线。与 0.1.0 一同发布的 LTS 政策，写在 Servo Book 的 LTS 文档里。

每六个月，基于当时最新的常规发行版切出一条新的 LTS 分支，支持期预计为九个月，其中包含迁移到下一个 LTS 所需的时间。
LTS 分支只接受安全修复。补丁发行版按需发布，没有固定日程。
范围仅限于 servo 库及其依赖，servoshell 被明确排除在外。
LTS 分支上不会提升最低支持 Rust 版本。
发布到 crates.io 是「尽力而为」— 文档提前警告，如果下游 crate 的 CVE 修复没有回传到旧版本，可能就需要改用 git 依赖。

发行记录说明，这份承诺不是一纸空文。v0.1.1(LTS) 是一次把 SpiderMonkey 升到 ESR 140.10 的依赖补丁(5 月 25 日发布到 crates.io)，而 v0.1.2(7 月初)把 SpiderMonkey 升到 ESR 140.12，纳入了 Mozilla 安全公告 MFSA 2026-48、2026-58 的修复，发行说明里写明有 24 项安全相关变更被回传到了 LTS。这意味着嵌入方现在有了一条能跟上 JS 引擎安全补丁的路径，而这恰恰触及了「把 Web 引擎内置进应用」时最令人担心的那部分运维成本。

不过，同一份文档里的限制条款，也照原文的意思如实转述一下 — Servo 是按「原样」(AS IS)提供的，包括安全性在内不作任何保证；LTS 是感兴趣的社区成员尽力而为的产物(目前明确列出的维护者只有一人)；由于处于 1.0 之前，生产环境使用需要审慎评估。其中有一句话尤其是核心 —

在渲染已知、可信内容的应用里使用 Servo，与把它当作渲染任意内容的浏览器来用，两者的风险画像完全不同。

桌面应用的嵌入场景大体属于前者，而 Servo 团队自己划出了这条界线。

那么碎片化问题解决了吗 — 没有，只是算法变了

诚实地算一笔账，是这样的。

今天的 Tauri 依然是 wry。 tauri crate 最新版本是 2026 年 7 月 1 日发布的 2.11.5，默认运行时依然是借用操作系统 webview 的 tauri-runtime-wry。要在 WebKitGTK、WKWebView、WebView2 这三个引擎上测试的现实，到 2026 年年中依然没变。Verso 运行时没能成为那个替代方案，反而停在了半路。

Servo 这条路径不是消除碎片化，而是把内置成本找了回来。 嵌入了 Servo 的应用，在任何操作系统上渲染都用同一个引擎，但这个引擎必须随应用一起分发 — Tauri 团队把常青版共享 Verso 列为长期课题，原因正在于此。至于体积会膨胀多少，我没能找到任何公开发布的、基于 tauri-runtime-verso 构建的应用的体积与内存实测数据 — 与其编造一个数字，不如老实写下「没有公开的实测数据」更准确。唯一确定的是方向：借用操作系统 webview 会更小，装进引擎会更大。

成熟度差距不是数量问题，而是种类问题。 WebKit、Chromium 是积累了数十年 Web 兼容性工作的引擎，而 Servo 连 1.0 的定义都还在讨论中。要在一个官方文档说「每次月度发布都可能出现破坏性变更」的 API 上搭建产品，要么就得落在六个月一次的 LTS 上，要么就得把升级的人力常年编进预算里。

现在该如何选择 — 判断标准

如果今天就必须上线一个生产环境的桌面应用 — 选项和 2025 年一样。体积、内存优先，就走 Tauri + wry，同时把三引擎测试成本编进 CI；渲染一致性没有商量余地，就接受 Electron 那一类的内置引擎方案。这方面的整体比较，在跨平台桌面应用 2026一篇里有。
如果好奇 Tauri + Servo 这个组合 — tauri-runtime-verso 现在仍然可以克隆下来跑，但要清楚地知道，这是一个锁定在 2025 年 9 月 versoview 0.0.9、提交已经停滞的实验。目前把产品搭在它上面并没有依据。
如果你是只渲染自家应用可信内容的嵌入方 — 这一次真正值得关注的，是 servo crate 本身。它能从 crates.io 获取，LTS 分支确实在做安全补丁回传，嵌入 API 的变更也会在月度文章里公告。把原型钉在 LTS(0.1.x)上，半年后再评估迁移到下一个 LTS 的成本，是一个现实的第一步。
不该用在哪里 — 渲染任意网页内容的场景(正是 Servo 文档自己划出的那条线)、承受不起 Web 兼容性问题的团队，以及只能依赖稳定 API 运转的组织。「1.0 之前」这句话不是摆设。

结语

2025 年春天描绘的那幅图景 — 「Verso 包裹 Servo，Tauri 搭载 Verso，从而摆脱操作系统 webview 碎片化」 — 并没有成真。人力和资金随着资助到期一起撤走，先停下来的是外面那层包装，仓库们淡然地记录了这个事实。而出乎意料的进展，反倒来自更底层。随着 Servo 本体具备了月度发布、crates.io 发布，乃至一条真正在做安全补丁回传的 LTS 分支，「把 Web 引擎作为库放进 Rust 应用」这句话，到 2026 年已经字面意义上变成了 cargo add servo。

碎片化问题本身并没有被解决。眼下能选的，依然只是「在三个引擎上测试」与「随身带着一个引擎」之间的权衡，而 Servo 只是刚刚作为一个可能改变后者成本结构的候选者，出现在了注册表上。下一个观察节点很清楚 — 2027 年初，第一条 LTS 九个月支持期结束时，第二条 LTS 分支是否如约而至。到那时再重新算一算，这场实验是否已经变成了基础设施。