Ladybird浏览器：从零构建的独立浏览器引擎

一个真正独立的浏览器引擎

在当今的浏览器市场，Chrome、Edge、Brave、Opera 等主流浏览器几乎都基于同一个内核——Google 主导的 Chromium/Blink。即便是 Firefox，也在市场份额持续萎缩的压力下艰难维持。整个 Web 生态高度依赖少数几家科技巨头掌控的渲染引擎，这让浏览器领域的多样性和独立性备受质疑。

浏览器引擎的垄断并非一朝一夕形成。要理解这段历史，需要回溯到更早的时期：2001 年，Apple 从 KDE 项目的 KHTML 引擎分叉出 WebKit，用于 Safari 浏览器。KHTML 是 KDE 桌面环境项目下的开源 HTML 渲染引擎，最初由 KDE 开发者在 1998 年为 Konqueror 浏览器开发。KDE 是 Linux/Unix 系统上最重要的桌面环境之一，其开发社区以高质量的 C++ 代码和 Qt 框架的深度使用著称。Apple 选择 KHTML 作为基础时曾引起开源社区的争议——虽然 LGPL 许可证允许这样做，但 Apple 早期将修改回馈上游的方式让 KDE 开发者难以有效整合，这段经历也促进了开源社区对企业参与开源方式的持续反思。

2008 年 Google 推出 Chrome 时采用了 WebKit 作为渲染引擎；2013 年，Google 因与 Apple 在架构方向上的分歧（主要围绕多进程架构的实现方式），从 WebKit 中分叉出 Blink 引擎，此后 Opera 放弃自研的 Presto 引擎转投 Chromium。Presto 曾以其出色的标准兼容性和小巧的体积著称，但维护一个独立引擎所需的持续投入——每年需要跟进数百项新的 Web 标准提案——让 Opera 这样规模的公司难以为继。2018 年微软也宣布放弃 EdgeHTML 转用 Chromium 内核，EdgeHTML 继承自 IE 时代的 Trident 引擎，微软在其上投入了大量重构工作，但最终仍然发现追赶 Blink 的更新速度过于吃力。这些决定虽然各有商业合理性，但客观结果是让 Blink 成为了事实上的 Web 标准裁判者。当一个引擎占据超过 70% 的市场份额时，网站开发者往往只针对该引擎测试，形成「只要 Chrome 能跑就行」的恶性循环，进一步压缩其他引擎的生存空间。

正是在这样的背景下，Ladybird 项目显得格外与众不同。它是一个「真正独立的网页浏览器」（Truly independent web browser），从零开始编写自己的引擎，不依赖任何现有的浏览器代码库。目前该项目在 GitHub 上已积累超过 65,000 颗星，拥有 3,100 多个 Fork，单日新增 star 数达到 190，社区热度持续攀升。

为什么「独立引擎」如此重要

Ladybird 的核心价值在于它没有沿用 Blink、WebKit 或 Gecko 中的任何一个。整个浏览器引擎、JavaScript 引擎、渲染管线都是用 C++ 从头构建的。这意味着它不会受制于任何一家商业公司的路线图，也为 Web 标准的实现提供了一个全新的参考实现（reference implementation）。

在软件标准领域，「参考实现」是指严格按照规范文档独立开发的实现版本，用于验证规范本身的完整性和可实现性。Web 标准的制定实际上涉及两个主要组织的协作：W3C（万维网联盟）由 Tim Berners-Lee 于 1994 年创立，负责制定 CSS、DOM、WAI-ARIA 等标准；而 HTML 标准自 2019 年起由 WHATWG（Web 超文本应用技术工作组）独家维护，采用 Living Standard 模式——即标准文档持续更新，不再有版本号的概念。WHATWG 由 Apple、Google、Mozilla 和 Microsoft 四家浏览器厂商共同运营，这意味着标准的制定权实际上掌握在这些实现者手中。一个完全独立的第四方实现者参与标准讨论，可以为标准制定过程引入不同的视角和利益诉求。

W3C 制定标准时遵循严格的流程：一项技术提案需要经历 Working Draft（工作草案）、Candidate Recommendation（候选推荐标准）、Proposed Recommendation（提议推荐标准）到最终的 W3C Recommendation（正式推荐标准）等多个阶段。其中一个关键门槛是：从候选推荐到正式推荐，至少需要两个独立的互操作实现通过测试，以证明该规范是可实现的且没有歧义。目前 Web 标准的主要实现者只剩下 Blink（Chrome/Edge）、WebKit（Safari）和 Gecko（Firefox）三家，而 WebKit 和 Blink 同源的技术背景使得某些实现差异难以暴露。Ladybird 作为完全独立的第四个引擎实现，可以暴露标准文档中的歧义或遗漏，从而推动标准本身的改进。这种价值在 Web 平台日益复杂的今天尤为重要——当标准文档中的模糊表述只有「参考 Chromium 的行为」这一种解决方式时，标准本身就已经失去了独立性。

对于一个日益被少数厂商垄断的领域来说，多一个独立的引擎实现，本身就是对 Web 开放性的重要贡献。它能帮助验证 Web 标准是否真正可以被独立实现，而不是变成某个厂商事实上的私有规范。

Ladybird的起源：从 SerenityOS 走出的独立项目

Ladybird 最初诞生于 SerenityOS 项目——一个同样从零编写的类 Unix 操作系统。项目发起人 Andreas Kling 最初只是想为 SerenityOS 打造一个浏览器组件，随着开发深入，Ladybird 逐渐成长为一个可以脱离操作系统、跨平台运行的独立项目。

SerenityOS 是 Andreas Kling 在 2018 年启动的个人项目，最初是他康复期间的编程练习。Andreas 此前曾在 Apple 的 WebKit 团队和 Nokia 的 Qt 团队工作，拥有丰富的浏览器引擎和系统级编程经验。该项目的独特之处在于几乎不使用任何第三方库，从内核、文件系统、GUI 框架到应用程序全部从零编写。这种「重新发明轮子」的哲学虽然在工程效率上不占优势，但为开发者提供了深入理解系统每一层的机会。SerenityOS 的视觉风格模仿了 90 年代末的桌面操作系统（如 Windows 2000 和 Mac OS 9），在开发者社区中积累了大量追随者，也为 Ladybird 培养了最初的核心贡献者团队。正是这种从零构建复杂系统的经验和文化，为 Ladybird 挑战浏览器引擎这一「最终 boss」提供了技术基础和团队信心。

2024 年，Ladybird 正式从 SerenityOS 中独立出来，成立了非营利组织进行运营，并获得了包括知名开发者在内的多方赞助支持。GitHub 联合创始人 Chris Wanstrath 和 Shopify 创始人 Tobi Lütke 等知名科技人士为该项目提供了资金支持，表明业界对独立浏览器引擎的广泛认可。这种非营利、由社区和捐赠驱动的模式，进一步强化了它「不受商业利益绑架」的定位——不同于 Mozilla 基金会长期依赖 Google 搜索引擎默认协议获取收入（每年约 4-5 亿美元，占 Mozilla 总收入的 80% 以上）的模式，Ladybird 通过多元化的捐赠来源避免了类似的利益冲突。Mozilla 的困境颇具警示意义：尽管 Firefox 的使命是对抗 Chrome 的垄断，但其绝大部分资金来源恰恰是 Google 支付的搜索引擎默认设置费用，这种结构性依赖使得 Mozilla 在涉及 Google 利益的决策上难以完全独立。Ladybird 通过接受多个不同来源的捐赠（个人开发者、科技企业家、基金会等），试图建立一种更可持续且不受单一金主掣肘的资金结构。

Ladybird的技术栈与架构

项目主要采用 C++ 编写，这既是出于性能考量，也延续了 SerenityOS 的技术传统。浏览器引擎开发是极其复杂的工程，涉及 HTML 解析、CSS 布局、JavaScript 执行、网络协议、图形渲染等诸多子系统。现代浏览器引擎被认为是人类工程史上最复杂的软件系统之一——仅 HTML 规范（由 WHATWG 维护的 Living Standard）就超过 10 万字，CSS 规范分布在数十个模块中（从 CSS Grid Layout 到 CSS Houdini，每个模块都是独立的规范文档），JavaScript 引擎需要实现 JIT（即时编译）才能达到可接受的性能。

现代 JavaScript 引擎的 JIT 编译采用多层架构：首先通过解释器快速启动代码执行，同时收集运行时类型信息（profiling）；当某段代码被频繁执行（即「热点代码」）时，基线编译器会将其编译为未经优化的机器码；如果热度继续上升，优化编译器则基于收集到的类型信息进行激进的推测性优化（如内联缓存、逃逸分析、循环展开等）。V8（Chrome）、SpiderMonkey（Firefox）和 JavaScriptCore（Safari）各自发展出了不同的 JIT 策略——例如 V8 的 Turbofan、SpiderMonkey 的 Warp、JavaScriptCore 的 FTL（Faster Than Light）编译器。纯字节码解释器与成熟 JIT 编译器之间的性能差距通常在 10-100 倍之间，具体取决于工作负载类型。对于计算密集型任务（如复杂的 JavaScript 框架渲染逻辑），JIT 编译器通过将热点代码编译为本地机器码，可以达到接近 C++ 的执行速度。LibJS 作为 Ladybird 的自研 JavaScript 引擎，目前主要使用字节码解释器，JIT 编译器的开发是未来提升性能的关键里程碑——这意味着当前运行现代 JavaScript 框架（如 React、Vue）时会明显慢于主流浏览器，但对于静态内容为主的网页，解释器性能通常已经足够。

此外，浏览器还需要处理 WebAssembly（一种可在浏览器中运行的低级字节码格式，允许 C++/Rust 等语言编译的程序以接近原生速度运行）、Web Workers（允许 JavaScript 在后台线程执行以避免阻塞 UI）、Service Workers（一种可拦截网络请求的后台脚本，是 PWA 离线功能的基础）、WebGL/WebGPU（浏览器中的 GPU 加速图形 API）等现代 API。作为参考，Chromium 项目的代码量超过 3500 万行，即便是相对精简的 Firefox 也有约 2000 万行代码。这解释了为什么过去二十年中几乎没有新的浏览器引擎从零诞生——上一个尝试是 Servo（由 Mozilla Research 在 2012 年启动，使用 Rust 编写）。

Servo 项目虽然未能成为完整的浏览器产品，但其技术遗产对整个行业产生了深远影响。Servo 的 CSS 引擎 Stylo 在 2017 年被整合入 Firefox 57（Quantum 更新），大幅提升了 CSS 样式计算的并行化能力；其 WebRender 组件也被 Firefox 采用，将页面合成推迟到 GPU 端执行。2020 年 Mozilla 大规模裁员后，Servo 被转移到 Linux 基金会下继续维护。2023 年，Servo 项目获得新的资金注入并重新活跃，与 Ladybird 形成了有趣的对比——两者都致力于独立引擎开发，但技术路线不同（Rust vs C++/Swift），且 Servo 更倾向于作为嵌入式引擎而非面向终端用户的浏览器。

Ladybird 团队正在逐步实现这些能力，核心组件包括：

• LibWeb：自研的网页渲染引擎，负责 HTML 解析和 CSS 布局
• LibJS：自研的 JavaScript 引擎
• 独立的网络协议栈和图形渲染管线

值得一提的是，项目也在积极评估引入 Swift 等更现代、更注重内存安全的语言，以应对 C++ 在内存安全方面的固有挑战。C++ 因其零成本抽象和精细的内存控制能力，长期是系统级软件的首选语言，然而研究表明约 70% 的安全漏洞源于内存安全问题（如缓冲区溢出、释放后使用、双重释放等），这在浏览器这种需要解析大量不可信输入的软件中尤为致命——Google Project Zero 的数据显示，Chrome 的高危漏洞中超过一半与内存安全相关。

Swift 通过自动引用计数（ARC）和严格的所有权模型提供编译期内存安全保证，同时保持接近 C++ 的性能。Apple 的 Safari 团队已经在部分组件中使用 Swift，Rust 则被 Mozilla 引入 Firefox 的关键安全组件（如 CSS 引擎 Stylo 和媒体解析器）。2024 年 2 月，美国白宫国家网络安全总监办公室（ONCD）发布报告，正式建议软件行业迁移到内存安全语言，Linux 内核也从 6.1 版本开始支持 Rust 编写驱动程序，Android 团队报告称引入 Rust 后内存安全漏洞比例从 76% 降至 24%。Ladybird 考虑引入 Swift，反映了整个系统编程领域向内存安全语言迁移的大趋势，也体现出团队对现代软件工程实践的务实态度——在不牺牲性能的前提下，用语言层面的保证消除整类安全漏洞。

当前开发进展与面临的挑战

作为一个仍在早期开发阶段的项目，Ladybird 目前主要面向开发者和技术爱好者。官方计划在未来几年内发布首个面向普通用户的 Alpha 版本（预计 2026 年左右）。

主要面临的现实困难

打造一个能与 Chromium 竞争的浏览器绝非易事：

• Web 标准的庞大复杂性：现代 Web 平台包含数千个标准和无数边缘情况，完整实现需要海量工程投入。仅 Web Platform Tests（WPT）测试套件就包含超过 170 万个测试用例，通过率是衡量浏览器引擎成熟度的重要指标。WPT 是一个由浏览器厂商共同维护的跨浏览器测试项目，覆盖从基础的 DOM 操作到最新的 Web API，每个测试用例都对应标准规范中的特定要求。Chrome 和 Firefox 的 WPT 通过率通常在 90% 以上，而 Ladybird 目前的通过率虽然在快速提升，但仍有显著差距。
• 网站兼容性挑战：许多网站针对 Chrome 优化，非主流引擎往往会遭遇兼容性问题。一些网站甚至通过 User-Agent 嗅探主动屏蔽非主流浏览器，这种做法虽然不规范但十分普遍。更隐蔽的兼容性问题来自于网站使用了 Chrome 特有的非标准行为——当某个 bug 存在足够久，大量网站会依赖这个 bug 的行为，使其变成事实标准。这种现象在 Web 历史上有充分先例：IE 时代的 quirks mode（怪异模式）就是为了兼容依赖 IE bug 的网站而保留的渲染模式，至今所有浏览器仍然实现了这一模式。
• 安全与性能要求：要达到生产级别的安全性和渲染性能，还有很长的路要走。现代浏览器需要实现进程沙箱化（将渲染进程隔离在受限权限的沙箱中，即使被攻破也无法访问系统资源）、站点隔离（Site Isolation，确保不同网站的内容在不同进程中渲染，防止 Spectre 等侧信道攻击跨站窃取数据）等复杂安全机制，同时还要保证 60fps 的流畅渲染。浏览器的进程沙箱化是一种纵深防御策略，利用操作系统级别的隔离机制限制被攻破进程的能力——在 Linux 上使用 seccomp-BPF 限制系统调用，在 Windows 上利用 Restricted Tokens 和 Job Objects，macOS 则使用 App Sandbox 和 entitlements 机制。实现完整的沙箱化需要将浏览器拆分为多个进程角色（浏览器主进程、渲染进程、GPU 进程、网络进程、插件进程等），并精心设计进程间通信（IPC）协议，确保高权限操作只在受信任的进程中执行。Chrome 在 2018 年全面启用站点隔离后，内存占用增加了 10-15%，这体现了安全性与资源效率之间的工程权衡。
• 人力资源有限：相比拥有数千名工程师的 Google，社区驱动项目的开发资源天然受限。Chrome 团队估计有超过 1000 名全职工程师，而 Ladybird 的核心贡献者目前仅有数十人。不过历史表明，精简团队在特定条件下也能取得突破——早期的 Firefox 和 WebKit 都是从小团队起步，关键在于是否能建立可持续的贡献者增长管道。开源项目的「贡献者漏斗」通常遵循一个规律：大量用户中只有少数会报告 bug，报告 bug 的用户中只有更少数会提交代码修复，而能持续贡献核心功能的开发者更是凤毛麟角。Ladybird 目前的策略是通过 YouTube 开发直播、详细的贡献者文档和友好的代码审查文化来降低参与门槛。

尽管如此，Ladybird 的存在本身就具有象征意义。它证明了在巨头垄断的格局下，社区驱动的独立浏览器引擎依然可能成长壮大。

Web多样性的希望：为什么Ladybird值得关注

Ladybird 或许短期内无法撼动 Chrome 的市场地位，但它的意义远不止于市场份额。它为 Web 生态提供了一个珍贵的独立选项，也为无数关注开放互联网的开发者带来了希望。

从历史角度看，Web 的健康发展始终依赖于多个独立引擎之间的良性竞争。2000 年代初期 Internet Explorer 一家独大时（市场份额一度超过 95%），Web 标准的推进几乎停滞——IE6 在 2001 年发布后，微软解散了浏览器团队的大部分人员，此后五年内没有发布重大更新，导致 Web 开发者被迫使用各种 hack 来应对 IE 的非标准行为。正是 Firefox（2004 年发布）和后来的 Chrome（2008 年发布）引入竞争，才推动了 HTML5、CSS3 等现代标准的快速发展。这段历史被 Web 开发社区称为「浏览器战争」的第二阶段，其核心教训是：没有竞争的市场必然导致创新停滞。

如今 Chromium 的支配地位虽然尚未导致明显的标准停滞，但已经出现了 Google 单方面推动争议性 API 的苗头。2023 年，Google 提出的 Web Environment Integrity（WEI）API 引发了广泛争议——该提案允许网站验证用户浏览器环境的「完整性」，批评者认为这本质上是一种 DRM 机制，会限制浏览器扩展、广告拦截器和辅助技术的使用，将 Web 从开放平台变为受控平台。虽然该提案在社区强烈反对下被搁置，但它暴露了单一引擎主导下的权力失衡。此外，Google 推动的 Manifest V3 扩展标准也限制了广告拦截扩展的能力——Manifest V3 用声明式网络请求 API（declarativeNetRequest）替代了旧的阻塞式 webRequest API，将可用的过滤规则数量限制在 33 万条以内（后提升至 33 万静态规则加 5000 动态规则），而主流广告拦截器如 uBlock Origin 的完整规则列表远超此限制。其他基于 Chromium 的浏览器虽然理论上可以保留旧 API，但长期维护分叉的成本使这种做法难以持续。这些事件让独立引擎的「制衡」角色显得愈发重要——当存在多个技术上独立的引擎时，任何一方的争议性决定都更容易被制衡和纠正。

在一个越来越同质化的浏览器世界里，一个「从零开始、真正独立」的项目获得 6.5 万颗星的关注，恰恰说明了社区对 Web 多样性的强烈渴望。无论你是前端开发者、开源爱好者还是关心互联网未来的普通用户，这个项目都值得持续关注。

核心要点