探索 Ladybird：非 Chromium 浏览器项目

Ladybird 是一款从零构建的 Web 浏览器引擎——不基于 Chromium、WebKit，也不属于 Gecko 谱系——由 Ladybird Browser Initiative 开发。该组织是一家 501(c)(3) 非营利机构，由 Andreas Kling 和 Chris Wanstrath 共同创立。这是十余年来首个真正意义上的独立浏览器引擎，其标准合规程度已值得前端开发者认真关注。本文将回答开发者在 Hacker News 或 X 上看到”Ladybird”成为热门话题后真正想知道的三个问题：它是否真实可信？2026 年的 alpha 版本是否具有实质意义？它是否会改变你所交付的 Web 产品？简短的答案是：是的、很可能、暂时还不会——但其发展轨迹才是真正值得关注的部分。

Ladybird 是什么，由谁构建

Ladybird 是一款独立浏览器引擎，与 Blink、WebKit 或 Gecko 没有任何共享代码，由 Ladybird Browser Initiative 这一注册 501(c)(3) 非营利机构负责治理。根据项目的组织页面，现任领导层包括：Andreas Kling 担任主席，Tim Flynn 担任秘书，Mike Shaver 担任财务主管。该项目最初是 Kling 个人爱好操作系统 SerenityOS 中的 HTML 查看器，后来独立成为一款跨平台浏览器。

对于质疑者而言，治理结构比任何功能列表都更能说明”这是否真实可信”。Ladybird 通过赞助和捐款获得资金，而非依赖广告收入或设备销售。GitHub 联合创始人 Chris Wanstrath 共同创立了该 Initiative，其家族承诺向其捐款 100 万美元，相关公告发布于 awesomekling.github.io。项目赞助商名单列于 ladybird.org（检索日期：2026 年 4 月），白金级赞助商包括 FUTO、Shopify 和 Cloudflare，黄金级赞助商包括人权基金会、Proton、Guillermo Rauch 和 Ohne Makler。由于赞助层级随项目发展而变化，请以官网为准进行核实。

这是最能说服质疑者的关键信息：有具名的法律实体、具名的负责人、具名的企业赞助商，以及可核实的资金承诺。Ladybird 绝非周末原型项目。

为何新浏览器引擎如此罕见

Web 运行在三大引擎之上——Google 的 Blink、Apple 的 WebKit 和 Mozilla 的 Gecko——真正意义上的新引擎极为罕见，因为入场成本极其高昂。上一次有新的独立引擎实现规模化普及，还是 Opera 仍在使用 Presto 的年代；这一局面于 2013 年终结，彼时 Opera 切换至基于 Chromium 的浏览器，而微软放弃 EdgeHTML 的过渡则以 2020 年基于 Chromium 的 Edge 稳定版发布而告终。时至今日，Web 在很大程度上依赖这三大渲染引擎，其中 Blink 占据浏览器使用量的主导份额（来源：StatCounter）。

构建一款新引擎极为困难，因为它必须通过数以万计的兼容性测试，并在 Web 规模下正确处理 HTML、CSS、JavaScript、图形、安全性、无障碍访问和性能。衡量这一覆盖范围的基准是 Web Platform Tests（WPT）测试套件，这是一个跨厂商合规项目。WPT 包含数百万个独立子测试；要匹配真实网站所依赖的行为——包括成熟引擎数十年来已发布的未记录怪异行为——正是这项工作历史上让独立引擎屡屡折戟的原因所在。一个严格遵循标准但导致依赖这些怪异行为的网站出现故障的实现，将无法通过唯一真正重要的商业测试：渲染现有 Web。

这正是 Ladybird 值得关注的背景。它并非在功能上竞争，而是试图跨越那道在过去十年的整合浪潮中几乎变得无法逾越的合规门槛。

Ladybird 架构解析

Ladybird 的多进程架构将渲染、图像解码和网络请求分离到各自独立的沙箱进程中，通过进程间通信进行协调。根据项目的文档和源码结构，引擎分为一个主 UI 进程和一组辅助进程：WebContent 负责渲染和脚本执行，ImageDecoder 负责图像解码，RequestServer 负责网络请求。每个 Web 内容进程均在沙箱中运行。

这种拆分的意义在于在进程边界处实现隔离。解码不可信图像数据——历史上内存损坏漏洞的常见来源——在 ImageDecoder 中进行，与渲染进程相互隔离。网络处理位于 RequestServer 中，与页面内容相互隔离。进程分离本身就是可验证的设计主张；这些边界正是 Ladybird 安全模型的所在，其设计参照了主流浏览器在过去十五年间所采用的多进程架构。

渲染和脚本工作被划分到一组库中，每个库负责平台的一个层次：

LibJS 值得特别关注，因为它并非对 V8 或 JavaScriptCore 等现有 JavaScript 引擎的薄封装——它是一个完整的实现，拥有自己的词法分析器、解析器、AST、字节码生成器和字节码解释器。这一细节对下一节至关重要，因为该流水线的前端正是项目最近最重要的工程工作所在之处。

语言策略：C++ 核心，Rust 推进中

Ladybird 的核心以现代 C++ 编写，但团队已开始将性能敏感和安全敏感的组件迁移至 Rust。2026 年 2 月，项目完成了 LibJS 前端流水线的 Rust 重写——涵盖词法分析器、解析器、AST、作用域收集器和字节码生成器——并默认启用该 Rust 流水线，详见 2026 年 2 月新闻简报。这是项目迄今最新、技术意义最为重大的进展，在早期报道中尚未涉及。

其动机与浏览器引擎采用 Rust 的标准理由相同：在解析不可信输入的代码路径中实现内存安全。JavaScript 解析器在每次页面加载时都会处理任意攻击者可控的文本，这使其成为语言层面内存安全保证能够消除整类漏洞的典型组件。定义清晰的互操作边界也使增量迁移成为可能——Rust 前端可以将字节码传递给现有的 C++ 解释器，无需进行全面重写。

这并非项目首次在 C++ 之外进行探索。Ladybird 此前曾尝试将 Swift 用于部分代码库，后来在决定采用 Rust 之前移除了所有 Swift 代码。从”我们在尝试 Swift”到”Rust 前端流水线默认发布”，这一转变标志着工程成熟度的提升：项目现在能够审慎地做出并撤回语言层面的决策，而非将 C++ 视为永久既定的选择。

标准合规性：Ladybird 的现状

截至 2026 年 4 月，Ladybird 报告通过了 2,067,263 项 Web Platform Test 子测试——较上一期的 2,003,537 项有所增长——详见 2026 年 4 月新闻简报；同时，在已导入的 53,207 项 test262 JavaScript 合规子测试中的 52,045 项上取得了 97.8% 的通过率。这些数字是 Ladybird 是一款严肃引擎而非演示项目的最有力证据。

有几点注意事项需要说明，以确保这些数字的客观性。WPT 子测试计数是一个绝对数值，而非完整测试套件的百分比；若要与其他引擎进行整体 WPT 通过率排名对比，请直接在 wpt.fyi 上核实并注明检索日期，因为测试套件规模和各浏览器结果处于持续变化之中。test262 数据的统计范围仅限于已导入的子测试，而非完整套件——Ladybird 导入其中一个子集并针对该子集进行报告。在这些限定条件下，整体情况是：一个 JavaScript 实现通过了其所运行的绝大多数合规测试，一个 Web 平台实现通过了数百万项 WPT 子测试。这已远超引擎能够正常渲染真实 Web 的门槛。

路线图与客观说明

官方网站明确将 2026 年面向 Linux 和 macOS 的公开 alpha 版本作为目标，详见 Ladybird 主页。Beta 和稳定版发布日期在二手报道中分别流传为 2027 年和 2028 年，但目前无法从 ladybird.org 核实，应视为参考性信息而非确定承诺。Pre-alpha 阶段的时间表容易延期，浏览器引擎的合规工作本质上是开放式的，因此 2026 年 alpha 版本之后的任何日期都是目标而非承诺。

平台支持范围比成品浏览器更窄，但也不仅限于 Linux。alpha 版本面向 Linux 和 macOS；Windows 支持正在积极开发中，基于 WSL2 的构建工作流已经存在，供希望在 Windows 上运行该引擎的开发者使用。截至本文撰写时，实际状态是软件可以构建和运行，但尚未准备好用于日常浏览——预期会有功能缺失和粗糙之处。

Ladybird 对前端开发者的意义

第四个独立浏览器引擎对前端开发者的意义，在于它作为合规性压力点的价值，而非作为需要适配的新浏览器。一个严格通过 WPT 并在真实网站出现故障时提交规范问题的项目，能够形成两三个引擎寡头格局所无法提供的问责机制。其价值是结构性的，与市场份额无关。

由于 Ladybird 的非营利结构没有需要保护的广告收入，也没有需要维护的设备生态系统，它是唯一一个面向完整终端用户浏览器、在结构上没有偏离 W3C 规范以服务商业议程动机的引擎。Servo 最初来自 Mozilla，现在隶属于 Linux 基金会，同样具有非商业立场，但目前作为可嵌入引擎而非完整浏览器产品进行开发。当你回想起 FLoC 是 Google 隐私沙盒的一项提案（后被 Topics 取代），以及智能跟踪防护是反映 Apple 平台优先级的 WebKit 功能时，这一区别便具体而清晰了。两者都折射出其母公司的商业背景；而一个没有此类背景的引擎则完全消除了这种压力。

引擎特有的渲染和脚本怪异行为——CSS 布局边缘情况、规范边界处的 JavaScript 行为差异——正是那类在多样化浏览器环境的生产流量中才会浮现的 bug，而非在针对单一引擎的本地测试中能够发现的问题。跨浏览器问题的 Session Replay 记录经常揭示出那些在开发者自己机器上从未复现的故障。更多独立实现通过同一合规测试套件，将缩小这些怪异行为得以隐藏的空间。

如何跟进和试用 Ladybird

Ladybird 是可在 Linux 和 macOS 上构建和运行的 pre-alpha 软件。跟踪它的权威方式是项目自身的渠道——二手报道在数周内便会过时。ladybird.org/news 定期发布新闻简报，包含合规数字、架构变更和里程碑更新——它是本文所有状态声明的主要来源。源码托管在 GitHub 的 LadybirdBrowser/ladybird 仓库中。

如需构建和运行，请遵循官方文档中的最新构建说明，而非任何第三方教程——在这样一个快速推进的项目中，依赖列表和构建命令会频繁变化。克隆仓库并安装依赖后，项目的构建和运行入口点是其 Meta 脚本：

git clone https://github.com/LadybirdBrowser/ladybird.git
cd ladybird
./Meta/ladybird.py run

./Meta/ladybird.py run 的形式已取代过时教程中常见的旧版 ladybird.sh 命令。对于在官方文档之外找到的任何具体依赖版本，请保持审慎态度；在开始之前，请查阅构建说明以了解当前的工具链要求。

Ladybird 是一款真实存在、治理规范、从零构建的浏览器引擎，正在通过严格的合规测试——它今天还不是可行的 Chrome 替代品，但却是十余年来 Web 在引擎多样性方面最具说服力的尝试。具体的下一步行动是将 ladybird.org/news 加入书签，并在每期新闻简报中关注合规数字；这些数字的变化轨迹，将比任何单一快照都更能告诉你这是否会改变你所交付的 Web 产品。

常见问题

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.