编程 Ladybird 深度解析：从零构建的独立浏览器引擎——C++/Rust 混合架构、多进程沙箱与 WebAssembly JIT 如何挑战 Chromium 统治地位

2026-07-06 09:12:10 +0800 CST views 17

Ladybird 深度解析：从零构建的独立浏览器引擎——C++/Rust 混合架构、多进程沙箱与 WebAssembly JIT 如何挑战 Chromium 统治地位

引言：为什么我们需要一个新的浏览器引擎？

2026 年的互联网，表面上百花齐放，实际上暗藏着一个令人不安的事实：全球超过 95% 的网页浏览量，由三个浏览器引擎承载——Blink（Chrome/Edge/Opera）、Gecko（Firefox）和 WebKit（Safari）。而这三个引擎，分别被 Google、Mozilla 和 Apple 三家巨头控制。

这意味着什么？意味着 Web 标准的走向，实质上由少数几家公司的商业利益决定。Google 推进 Manifest V3 打压广告拦截器，Apple 对 WebKit 的保守策略限制了 iOS 上所有浏览器的能力，Mozilla 在财务困境中艰难求存。当引擎的控制权高度集中时，"开放的 Web" 就成了一句空话。

正是在这样的背景下，Ladybird 项目横空出世。它不是又一个 Chromium 换皮，不是 Firefox 的分支，而是从第一行代码开始，完全从零构建的全新浏览器引擎。更令人惊讶的是，这个项目脱胎于一个程序员的个人操作系统项目（SerenityOS），如今已经发展成为拥有 Shopify、Cloudflare 等白金赞助商的 501(c)(3) 非营利组织，目标是在 2026 年发布面向开发者和早期采用者的 Alpha 版本。

本文将深入剖析 Ladybird 的技术架构、核心组件、安全模型、性能策略以及它正在经历的 C++ 到 Rust 的渐进式迁移，带你全面了解这个可能是近十年来最雄心勃勃的开源基础设施项目。

一、项目起源：从 SerenityOS 到独立浏览器

1.1 SerenityOS：一个人的操作系统

Ladybird 的故事必须从 SerenityOS 讲起。2018 年，瑞典程序员 Andreas Kling 开始了一个看似疯狂的项目：从零编写一个完整的操作系统，包括内核、图形界面、浏览器、邮件客户端、文本编辑器——所有东西都是自己写的，不依赖现有的开源组件。

SerenityOS 的浏览器组件叫做 LibWeb，JavaScript 引擎叫做 LibJS，WebAssembly 实现叫做 LibWasm。这些名字一直沿用至今。

1.2 独立出来

到 2022 年，SerenityOS 的浏览器组件已经足够成熟，能够渲染真实世界的网站。Andreas Kling 决定将浏览器部分独立出来，成立 Ladybird 项目。2024 年，Ladybird Browser Initiative 作为 501(c)(3) 非营利组织正式成立。

与 SerenityOS "一切从零写" 的文化不同，独立后的 Ladybird 开始务实地下使用第三方库处理常见的底层功能——图片解码、音视频格式、加密、图形渲染等，包括其他浏览器也在用的那些库。但浏览器引擎的核心——布局引擎、JS 引擎、网络栈——仍然是从零构建的。

二、整体架构：多进程模型与进程隔离

2.1 进程拓扑

Ladybird 采用经典的多进程架构，但有自己的设计选择：

┌─────────────────────────────────────────────────┐
│                  UI Process (主进程)              │
│  ┌──────────┐  ┌──────────┐  ┌──────────────┐  │
│  │ 标签管理  │  │ 下载管理  │  │  浏览历史    │  │
│  │ 垂直标签  │  │ DevTools  │  │  书签系统    │  │
│  └──────────┘  └──────────┘  └──────────────┘  │
└─────────┬──────────┬──────────┬─────────────────┘
          │          │          │
    ┌─────▼─────┐ ┌──▼──────┐ ┌▼──────────────┐
    │ WebContent│ │ImageDec │ │ RequestServer │
    │ (每标签页) │ │  oder   │ │   (网络)      │
    │  渲染进程  │ │  进程   │ │    进程       │
    └───────────┘ └─────────┘ └───────────────┘
          │
    ┌─────▼─────────────┐
    │    Compositor      │
    │  (合成器进程)       │
    │  GPU 独立沙箱      │
    └───────────────────┘

关键设计决策：

每个标签页独立进程：WebContent 进程是 per-tab 的，一个标签页崩溃不会影响其他标签页。这是现代浏览器的标准做法，但 Ladybird 的实现是完全自研的。
图片解码进程外置：ImageDecoder 作为独立进程运行，恶意图片文件无法直接攻击渲染引擎。
网络请求进程外置：RequestServer 处理所有网络请求，与渲染进程隔离。
合成器进程独立：2026 年 5 月，Ladybird 将合成器（Compositor）移入独立进程，6 月进一步将 Canvas 和 WebGL 渲染移入合成器进程。

2.2 IPC 机制

Ladybird 使用 Mach port（macOS）和 Unix socket 实现进程间通信。渲染进程通过 IPC 将绘制指令发送给合成器进程，合成器进程负责最终的像素合成和 GPU 操作。

这种架构的核心收益是安全性：WebContent 进程不再需要直接访问 GPU，即使攻击者通过恶意网页代码获得了渲染进程的执行权限，也无法直接操作 GPU 或访问其他进程的内存。

三、核心组件深度解析

3.1 LibWeb：从零构建的 Web 渲染引擎

LibWeb 是 Ladybird 的核心，负责 HTML 解析、CSS 渲染、DOM 管理和布局计算。它是一个完整的 Web 渲染引擎，不依赖 Blink、WebKit 或 Gecko 的任何代码。

HTML 解析器

Ladybird 的 HTML 解析器实现了 WHATWG HTML 规范中的完整解析算法，包括：

跨站脚本（XSS）防护的状态机
投机解析（Speculative Parsing）：在等待脚本加载时预先解析后续 HTML，2026 年 4 月实现
2026 年 2 月开始将 HTML 解析器迁移到 Rust

CSS 引擎

LibWeb 的 CSS 引擎已经支持了大量现代 CSS 特性：

Container Queries 和容器相对单位（cqw, cqh, cqi 等）
CSS Subgrid
CSS Anchor Positioning
contrast-color() 函数
@property 注册的自定义属性
progress() 数学函数
@scope、@counter-style
CSS if()、inherit()、@function

布局引擎

Ladybird 实现了完整的 CSS 盒模型、Flexbox 和 Grid 布局。2026 年 6 月，WPT（Web Platform Tests）得分从 2,075,546 提升到 2,078,912，增加了 3,366 个通过的子测试。

3.2 LibJS：JavaScript 引擎

LibJS 是 Ladybird 自研的 JavaScript 引擎，支持完整的 ECMAScript 规范。它的架构包括：

JavaScript 源码
      │
      ▼
┌──────────┐
│  Lexer   │  词法分析（已迁移到 Rust）
└────┬─────┘
     ▼
┌──────────┐
│  Parser  │  语法分析（已迁移到 Rust）
└────┬─────┘
     ▼
┌──────────┐
│   AST    │  抽象语法树（已迁移到 Rust）
└────┬─────┘
     ▼
┌──────────┐
│ Bytecode │  字节码生成（已迁移到 Rust）
│Generator │
└────┬─────┘
     ▼
┌──────────┐
│Interpreter│  汇编级解释器（全平台统一）
└────┬─────┘
     ▼
┌──────────┐
│   JIT    │  Cranelift JIT 编译器
└──────────┘

汇编级解释器

2026 年 3 月，Ladybird 实现了手写的汇编级字节码解释器，比之前的通用解释器快得多。6 月，这个解释器在 Windows 上也启用了，从而删除了旧的通用字节码解释器，全平台统一到一个代码路径。

Cranelift JIT

Ladybird 使用 Cranelift 作为 JIT 编译器后端。Cranelift 是一个用 Rust 编写的代码生成库，也被 Wasmtime 等项目使用。2026 年 5 月，基于 Cranelift 的 JIT 编译器上线，能够将热点 JavaScript 代码编译为原生机器码。

UTF-16 字符串统一

2026 年 6 月，LibJS 将内部字符串表示从混合编码统一为 UTF-16，与 JavaScript 规范中对字符串的定义一致，消除了大量的编码转换开销。

3.3 LibWasm：WebAssembly 实现

LibWasm 是 Ladybird 的 WebAssembly 运行时，支持：

WebAssembly 1.0 核心规范
WebAssembly GC（垃圾回收）提案——支持 struct 和 array 引用类型，这是 Kotlin、Dart、Java 等语言编译到 Wasm 的基础
异常处理提案
基于 Cranelift 的 JIT 编译

WebAssembly GC 的支持使得 Ladybird 能够运行更多使用高级语言编译到 Wasm 的 Web 应用，这是一个重要的里程碑。

3.4 LibCrypto / LibTLS：加密与传输安全

Ladybird 自研了加密库 LibCrypto 和 TLS 库 LibTLS，实现 HTTPS 连接。在独立出来之后，也开始使用部分成熟的第三方加密库来增强安全性。

四、安全架构：纵深防御的设计哲学

4.1 多层沙箱

2026 年 6 月，Ladybird 在安全方面迈出了重要一步——辅助进程开始在真实的沙箱中运行：

Linux：使用 seccomp-bpf 和 Landlock 进行系统调用过滤和文件系统隔离
macOS：使用 Seatbelt profiles 进行沙箱隔离

沙箱默认开启，不需要用户手动配置。

4.2 堆分区（Heap Partitioning）

Ladybird 实现了堆分区策略，将不同类型的内存数据隔离到不同的堆区域：

字符串数据独立分区
ArrayBuffer 底层存储独立分区
JS 对象属性存储独立分区

这种设计可以防止类型混淆攻击（type confusion），即使攻击者能够写入某个堆区域，也无法轻易篡改安全敏感的数据结构。

4.3 Canvas 隔离

跨域图片数据现在被追踪用于 canvas 污染检测，toDataURL() 和 toBlob() 在污染的 canvas 上会被拒绝执行。这防止了通过 canvas 读取跨域图片数据的信息泄露攻击。

4.4 内存安全的解码路径

Ladybird 在关键的解码路径上引入了内存安全的语言和库：

文本编码/解码：迁移到 Firefox 的 Rust 实现 encoding_rs
GIF 解码：迁移到 Google 的 Wuffs（一种专门为安全解码设计的语言）
HTML 解析器：正在逐步迁移到 Rust

4.5 Fuzzing

Ladybird 持续进行模糊测试（fuzzing），2026 年 6 月修复了一批 fuzzer 发现的崩溃和未定义行为问题，涉及 DOM、布局、图片解码和 CSS 像素计算等多个模块。

五、从 C++ 到 Rust：渐进式迁移策略

5.1 为什么选择 Rust？

Ladybird 最初在 2024 年评估过 Rust，但当时因为 Rust 不擅长 C++ 风格的 OOP（Web 平台的对象模型有很深的继承层次和垃圾回收）而被拒绝。

经过又一年的探索后，团队做出了务实的选择：

安全保证：Rust 的所有权模型在编译期防止数据竞争和内存安全问题
生态成熟：Firefox 和 Chromium 都已开始引入 Rust
社区基础：很多贡献者已经熟悉 Rust
之前的尝试：尝试过 Swift，但 C++ 互操作不够成熟，Apple 生态之外的平台支持有限

5.2 LibJS 的 Rust 迁移

第一个迁移目标是 LibJS 的前端部分（词法分析器、语法解析器、AST、字节码生成器），因为：

相对自包含，与引擎其他部分的耦合较少
有 test262（52,898 个测试）的完整覆盖
验证标准明确：字节级相同的输出

迁移过程：

Andreas Kling 使用 Claude Code 和 Codex 进行辅助翻译，但强调这是人类主导的翻译，不是自主代码生成：

由他决定移植的顺序和 Rust 代码的结构
数百个小提示（prompt），引导 AI 代理到正确方向
初始翻译后，用不同模型进行多轮对抗性审查

迁移结果：

约 25,000 行 Rust 代码
整个移植耗时约两周（手动翻译需要数月）
test262：52,898 个测试，零回归
Ladybird 回归测试：12,461 个测试，零回归
所有 JS 基准测试无性能回归

代码风格：

当前的 Rust 代码有明显的"从 C++ 翻译"痕迹——有意模仿 C++ 的寄存器分配模式，确保两个编译器管线产生完全相同的字节码。团队明确表示，等 C++ 管线退役后，会逐步将代码重构为更地道的 Rust 风格。

5.3 渐进式策略

Ladybird 的 Rust 迁移不是一次性重写，而是渐进式的：

C++ 仍然是主要开发语言
Rust 迁移是"支线工作"，长期运行
新的 Rust 代码通过定义良好的互操作边界与现有 C++ 代码共存
由核心团队管理迁移的优先级和顺序

这种策略避免了"大爆炸式重写"的风险，同时稳步提升代码的内存安全性。

六、GPU 架构与渲染流水线

6.1 合成器进程

2026 年 5 月，Ladybird 将合成器移入独立进程。合成器负责将页面的各个层（layers）合成为最终显示在屏幕上的像素。

6 月，Canvas 2D 和 WebGL 渲染也被移入合成器进程：

Canvas 2D：绘制命令列表在合成器进程中回放和光栅化
WebGL：命令通过共享内存流式传输到合成器进程

6.2 安全收益

将 GPU 访问集中到合成器进程的核心安全收益：

WebContent 进程不再需要直接 GPU 访问权限
即使渲染进程被攻破，攻击者也无法直接操作 GPU
WebGL 命令在合成器进程中经过验证后才提交给 GPU

6.3 异步合成

Pinch-zoom 在合成器进程中异步处理，即使主线程繁忙，缩放操作仍然保持响应。这种设计类似于 Chromium 的 viz（Visual）合成器架构。

七、浏览器功能与用户体验

7.1 下载管理

2026 年 6 月实现的下载功能：

工具栏指示器显示下载进度
about:downloads 页面列出所有下载
支持取消下载
退出时如有进行中的下载会弹出确认对话框
下载在 UI 进程中管理，关闭发起下载的标签页不会中断下载

7.2 浏览历史

about:history 页面，支持搜索和删除
右键/长按前进后退按钮显示原生历史菜单
历史数据存储在 UI 进程中（从渲染进程移出，提升安全性）

7.3 DevTools

Ladybird 的开发者工具在快速完善：

Storage 面板：查看和修改 cookies、localStorage、sessionStorage、IndexedDB
CSS 规则检查：显示计算值背后的各个声明，被覆盖的用删除线标记，无效的标红，支持跳转到源码
脚本源码视图：支持美化打印、代码折叠、搜索、跳转到定义

7.4 媒体播放

可调节播放速度
使用 Chromium 的 WSOLA 算法进行时间拉伸，保持音调不变
静音媒体默认允许自动播放（三态策略：允许静音自动播放、需要用户交互、完全阻止）

7.5 垂直标签

Ladybird 原生支持垂直标签栏：

可以放置在左侧或右侧
折叠状态下显示音频图标和关闭图标
标签悬停预览（基于缓存的 WebContent 位图，不触发重绘）

八、Web 平台兼容性进展

8.1 WPT 得分

Web Platform Tests 是衡量浏览器标准兼容性的权威基准。Ladybird 的 WPT 得分在持续增长：

2026 年 6 月：2,078,912 个通过的子测试
单月增长：3,366 个

虽然与 Chromium 和 Firefox 的得分还有差距，但考虑到这是一个从零构建的引擎，这个进度已经相当惊人。

8.2 已验证可用的网站

根据官方月报，以下网站在 Ladybird 上已经可以正常工作：

WhatsApp Web：不再显示"不支持的浏览器"对话框，能够到达 QR 登录界面
ChatGPT：减少冗余的样式失效计算
GitHub：长 PR 列表中的链接悬停更快
tweakers.net：contrast-color() 修复了橙色横幅中不可读的文本
rightmove.co.uk：修复了导航栏中的伪元素变换问题

8.3 CSS 特性覆盖

Ladybird 已经支持了大量现代 CSS 特性，这在从零构建的引擎中是非常难得的：

特性	状态
Container Queries	✅ 已支持
容器相对单位 (cqw/cqh 等)	✅ 已支持
CSS Subgrid	✅ 已支持
CSS Anchor Positioning	✅ 已支持
contrast-color()	✅ 已支持
@property 注册自定义属性	✅ 已支持
progress() 数学函数	✅ 已支持
@scope	✅ 已支持
@counter-style	✅ 已支持
ScrollTimeline	✅ 已支持

九、与现有浏览器引擎的对比

9.1 架构对比

维度	Ladybird	Chromium (Blink)	Firefox (Gecko)	Safari (WebKit)
核心语言	C++ + Rust	C++ + Rust	C++ + Rust + JavaScript	C++ + Objective-C
进程模型	多进程	多进程	多进程（Fission）	多进程
JS 引擎	LibJS (自研)	V8	SpiderMonkey	JavaScriptCore
JIT 后端	Cranelift	自研	WasmCranelift/Warp	LLVM B3/ARM64
沙箱	seccomp/Landlock/Seatbelt	seccomp/AppContainer	seccomp/AppContainer	Seatbelt
开源许可	BSD-2-Clause	BSD-3-Clause	MPL 2.0	BSD/LGPL
控制方	非营利组织	Google	Mozilla 基金会	Apple

9.2 独特优势

真正的独立性：不受任何商业公司的控制，技术决策完全由 Web 标准驱动
从零构建的安全性：没有历史包袱，可以采用最新的安全最佳实践
现代化的语言选择：积极引入 Rust，比其他引擎更系统化
非营利治理：501(c)(3) 组织，赞助商无权干预技术决策

9.3 面临的挑战

Web 兼容性差距：与 Chromium 相比，WPT 得分还有很大差距
团队规模：全职工程团队很小，与 Chromium 的数千人团队不可同日而语
生态惯性：很多网站只为 Chromium 优化
性能差距：在 JavaScript 密集型基准测试中可能落后于 V8 和 SpiderMonkey

十、开发流程与社区治理

10.1 代码贡献模式变更

2026 年 6 月，Ladybird 做出了一个重大决定：改为仅维护者可提交代码，不再接受公众的代码贡献。

这并不意味着项目闭源——Ladybird 仍然完全开源，社区仍然可以通过以下方式参与：

提交 Bug 报告
创建问题还原（reduction）
测试网站兼容性
安全报告
标准讨论

这个决策的背景是：随着项目接近 Alpha 发布，需要更严格地控制代码质量和开发方向。

10.2 资金模式

Ladybird 完全依赖捐赠和赞助：

白金赞助：$100,000/年（Shopify、Cloudflare、FUTO）
黄金赞助：$50,000/年
白银赞助：$10,000/年
个人捐赠：通过 Donorbox

所有赞助都是无限制捐赠，赞助商没有董事会席位，不参与技术决策。

十一、构建与贡献指南

11.1 本地构建

# 克隆仓库
git clone https://github.com/LadybirdBrowser/ladybird.git
cd ladybird

# 一键运行（自动处理依赖）
./Meta/ladybird.py run

11.2 系统要求

Linux：需要安装 CMake、Ninja、GCC 或 Clang
macOS：需要 Xcode Command Line Tools
Windows：CI 已支持 JS 引擎的 Windows 构建，完整浏览器支持计划中

11.3 项目结构

ladybird/
├── AK/                  # 基础库（字符串、容器、智能指针等）
├── Ladybird/            # 浏览器应用程序
├── Meta/                # 构建脚本和工具
├── Tests/               # 测试套件
├── Toolchain/           # 编译工具链配置
├── Userland/            # 核心库
│   ├── Libraries/
│   │   ├── LibWeb/      # Web 渲染引擎
│   │   ├── LibJS/       # JavaScript 引擎
│   │   ├── LibWasm/     # WebAssembly 运行时
│   │   ├── LibCrypto/   # 加密库
│   │   ├── LibTLS/      # TLS 实现
│   │   ├── LibHTTP/     # HTTP 客户端
│   │   └── ...
│   └── Services/
│       ├── WebContent/  # 渲染进程
│       ├── ImageDecoder/# 图片解码进程
│       ├── RequestServer/# 网络请求进程
│       └── ...
└── Documentation/       # 文档

十二、对未来 Web 生态的影响

12.1 打破引擎垄断

如果 Ladybird 成功发布 Alpha 并逐步走向成熟，它将成为 21 世纪第一个真正独立的新浏览器引擎。上一个从零构建并达到实用水平的引擎是 KDE 的 KHTML（WebKit 的前身），那已经是 2000 年代初的事了。

12.2 推动标准实现

一个独立的引擎意味着 Web 标准可以有第三个独立的实现。W3C 的标准推荐通常要求至少两个独立实现，Ladybird 的存在可以让标准制定过程更加健康。

12.3 安全研究价值

一个从零构建的引擎是安全研究的宝贵目标。它没有 Chromium 和 Firefox 积累了几十年的历史漏洞模式，但也可能暴露全新的攻击面。Ladybird 的 fuzzing 工作和安全审计将推动浏览器安全研究的进步。

12.4 Rust 在系统编程中的实践

Ladybird 的 C++ 到 Rust 渐进式迁移，为大型 C++ 项目的安全迁移提供了一个可参考的范本。它的经验——如何定义互操作边界、如何验证迁移正确性、如何管理迁移优先级——对整个行业都有参考价值。

总结与展望

Ladybird 是一个令人兴奋的项目。它代表了 Web 的一种可能性——一个不被商业利益控制、由社区驱动、从第一行代码就以安全和标准合规为目标的浏览器引擎。

从技术角度看，Ladybird 的架构选择是务实而前瞻的：

多进程架构与现代安全最佳实践一致
C++ 到 Rust 的渐进式迁移避免了大爆炸式重写的风险
Cranelift JIT 为 JavaScript 和 WebAssembly 提供了高性能的执行环境
堆分区和沙箱实现了纵深防御

从项目治理角度看，501(c)(3) 非营利组织的形式、赞助商无技术决策权的承诺、以及仅维护者提交的代码管理模式，都显示了团队对项目长期健康发展的认真态度。

当然，挑战依然巨大。Web 兼容性是一个长期工程，团队规模的限制意味着不可能在所有领域都与 Chromium 竞争。但 Ladybird 不需要成为最好的浏览器——它只需要成为一个足够好的、真正独立的浏览器，就已经是对整个 Web 生态的巨大贡献。

2026 年的 Alpha 发布将是一个历史性的时刻。无论你是 Web 开发者、安全研究者、Rust 爱好者，还是仅仅关心开放互联网的未来，Ladybird 都值得你的关注和支持。

项目地址：https://github.com/LadybirdBrowser/ladybird
官网：https://ladybird.org
Discord 社区：https://discord.gg/nvfjVJ4Svh
月报 RSS：https://ladybird.org/posts.rss