Ladybird：从零写浏览器引擎，现在走到了哪一步

判断：它解决的不是「再造一个浏览器」

浏览器引擎是赢者通吃的生意。桌面流量基本被 Chromium（Chrome、Edge、Brave 等）、Gecko（Firefox）和 WebKit（Safari）三家瓜分，其中 Chromium 系占大头。它们共享一个特征：引擎都从既有代码库演进或 fork 而来。上一个认真从零写起的引擎是 2012 年的 Servo，但它定位是可嵌入引擎，2020 年核心团队随 Mozilla 裁员散去，2023 年起才由 Igalia 重新推动，从未把「规范符合度」当主战场。十多年来，真正从零起步、并把规范符合度做到值得关注的独立引擎，Ladybird 是第一个——不 fork 上述任何一家，代码全部原创（官方 FAQ 原话：不用 Blink、WebKit、Gecko 的代码），由 501(c)(3) 非营利组织 Ladybird Browser Initiative 治理。

它真正要回答的问题不是「再给用户一个浏览器」，而是一场可行性实验：没有商业公司背书、没有现成引擎代码可抄，靠赞助运行的非营利团队，能把 Web 引擎的规范符合度推到什么水平。目前的答案是：WPT（Web Platform Tests）通过子测试 208 万+，test262（ECMAScript 官方一致性套件）通过率 97.8%。「从零写引擎」从口号变成了可验证的进度。

对读者来说，现阶段最确定的价值不在产品，而在代码库：一个可读、可改、能对照规范逐条检查的引擎实现样本。

系统地图：进程分工 + 一组库

Ladybird 是多进程浏览器：主 UI 进程管窗口和标签页，每个标签页一个独立的 WebContent 渲染进程，图片解码和网络请求分别由 ImageDecoder、RequestServer 两类进程承担。

多进程的思路和现代浏览器（如 Chromium）一致，但实现全部自研：HTML 解析、CSS 样式与布局、JS 引擎、WebAssembly、TLS，一路到事件循环和进程间通信，都是仓库自己的代码，不依赖 Skia、V8、NSS 这类浏览器领域现成的轮子。「独立引擎」在这里是完整含义——不是换壳，而是全栈自研。沙箱也在收紧：2026 年 6 月起，各服务进程在 Linux（seccomp/Landlock）和 macOS（Seatbelt）上默认沙箱化，WebContent 不再直接接触 GPU；8 月又把 Wasm 编译拆成独立服务进程，页面进程自此彻底失去 fork 权限。

这套库最初继承自 SerenityOS——创始人 Andreas Kling 的个人操作系统项目，2024 年 7 月浏览器部分独立出来成立 Ladybird。库的演进方向从此由 Ladybird 决定，但起源留下烙印：不少组件按「系统库」而非「浏览器专用库」的形态设计。

问题拆分：先分清三件容易混淆的事

• 「独立引擎」和「单一语言」是两回事。Ladybird 主流代码是 C++，但正逐步迁向 Rust，二者长期共存。独立指的是不抄既有引擎，不是只用一种语言。
• 「不 fork 引擎」不等于「每样都自研」。PDF 用打包进来的 pdf.js 渲染，调试器对接 Firefox 的 DevTools 协议，独立的是引擎核心，不是每个功能都要重造。
• 「规范符合度高」和「能跑所有真实网站」之间还有一段路。真实网站依赖大量文档外的历史行为（quirks），这是独立引擎最容易翻车的地方。Ladybird 甚至需要在 UA 字符串里带上 Chrome/AppleWebKit 字样，很多站点才肯给它正常内容。

这三条界线，决定了后面怎么看它的架构和数据。

核心机制：四条主线

1. 多进程：把不安全操作踢出去

浏览器漏洞的两类高发入口是「恶意图片触发解码器内存损坏」和「网络协议解析缺陷」。Ladybird 把这两类操作各放独立进程，即使解码器或网络栈被攻破，攻击者也够不到渲染进程的堆。每个标签页一个渲染进程再加沙箱，一页崩溃不会拖垮整个浏览器。进程外解码和进程外网络，是这个架构里最值得抄的两个点。

2. Rust 迁移：从可验证的组件下手

Ladybird 与 Rust 的关系经历了一次反转。2024 年首次评估时 Rust 被拒——理由是不擅长 C++ 式 OOP；试过 Swift，又因 C++ 互操作始终不成熟、Apple 生态之外平台支持有限而作罢。2026 年 2 月团队下了务实决定：LibJS 的前端管线（词法分析、语法解析、AST、作用域收集、字节码生成）整体重写为 Rust，约 25,000 行，前后花了约两周。翻译由 Claude Code 和 Codex 完成，但全程人工主导，之后还让不同模型做多轮对抗式审查。验证方式是逐字节比对：52,898 个 test262 测试加 12,461 个项目自带测试，新旧管线输出一致、零回归，随后默认启用——LIBJS_CPP=1 切回 C++ 管线，LIBJS_COMPARE_PIPELINES=1 让双管线同步跑、随时对账。

先动 JS 前端而不是整个引擎，因为它是一条边界清晰的纯函数管线：源码进、字节码出，能用测试套件穷举验证「改坏了没有」。7 月延续同一思路，把样式系统和布局引擎迁到 Rust，官方给的理由是内存安全，以及为并行化铺路——样式改为不可变共享值之后，多线程重排样式才有地基。8 月再下一城：CSS 解析器、计算样式的存储与计算、绘制管线（display list 与命中测试）全部转为 Rust 独占，旧 C++ 实现删除；C++ 与 Rust 改用同一种字符串表示，跨界零拷贝。至此 Rust 代码约 18 MB，已有 C++ 体量的四成多。迁移节奏是挑可验证、可并行化的组件先落地，不是为 Rust 而 Rust。

3. JS 解释器：造一门带类型的语言

LibJS 解释器原本用一套带宏的汇编式方言手写，183 个字节码 handler：没有东西知道某个位置存的是整数，没有东西检查值写入先于读取，关键决策埋在 coerce_to_int32s 这类宏里；旧的字节码生成器也不做优化，源码里冗余的加载会原样变成解释器里的冗余加载。团队为此造了门叫 flap 的类型语言（名字取自瓢虫扇翅的声音），构建时由编译器翻译成 x86-64 和 AArch64：类型可检查，热/冷路径物理分离——常规 JS 只触碰解释器里小而热的部分，小到能一直待在指令缓存里。切换本身性能中性——官方原话是「这正是我们想要的结果」，收益在切换之后：引入 specialize 机制（specialize BitwiseXor(rhs: Int32); 一行描述，编译器自动生成特化 handler 和选择逻辑），BitwiseXor 的热路径从 19 条指令减到 14 条，在计算密集的 JS 基准上换来约 5%。

4. 性能工程：以真实站点为靶子

月报里大量优化是「开着某个真实站点，用 profiler 找热点，改掉，再验证」。这类数字不能跨站点推广，但能说明工程节奏：

• Gmail 收件箱加载砍掉约 1 秒（2026-01）：缓存 parser 数据省约 400ms，布局与样式优化再省约 500ms，外加 getComputedStyle() 去掉不必要的重排。
• Discord 从约 65 FPS 到 120 FPS（2026-02，M4 MacBook）：跳过零面积裁剪下的命令、改 mask 合成方式。
• 动画图片改按需解码，仅 cloudflare.com 一处就省 1 GiB+ 内存（2026-02）。
• WebGL 命令走共享内存，纹理密集页面主线程占用从约 40% 降到约 6%（2026-07）。
• Strava 一个持续膨胀的活动页，内存从 17.8 GiB 降到 61 MiB（2026-08）。

8 月起，月报开始同时报跨站点合成基准：一个月内 Speedometer 2 从约 47 涨到约 64，Speedometer 3 从约 2.5 到约 3.9，StyleBench 从约 3.5 到约 83——这与新样式引擎落地处在同一时期。

一次页面加载如何流过系统

用「地址栏输入 URL 回车」这个最小任务，串起整条链路：

1. 主 UI 进程把导航意图经 IPC 交给 WebContent 渲染进程
2. WebContent 经 RequestServer 发请求，TLS 握手走 LibTLS
3. 响应体边下载边解析；遇到同步脚本时，推测式解析器提前扫描后续资源并预取
4. 字节码生成已挪到后台线程池，仅 YouTube 一处就移出约 200ms 主线程时间
5. LibWeb 构建 DOM/CSSOM，算样式、排布局，每个 Navigable 独立栅格化
6. 图片交给 ImageDecoder 进程解码，结果经 IPC 回传
7. compositor 只重绘变化区域，把帧合成上屏；WebGL 场景走共享内存避免每帧拷贝

每一步后面都站着验证：test262 在每次 push 和每个 PR 上自动跑（专用 CI workflow），WPT 通过数按月公开跟踪。「规范符合度」不是汇报口径，而是 CI 里跑出来的数字。

benchmark 解读：这些数字说明了什么

WPT 通过数（2026-08 月报：2,088,677 个通过的 subtest，当月净增 9,657；7 月只涨了 108）。WPT 是跨厂商的规范一致性套件，测的是引擎对标准的实现程度。读这个数字要先看口径：2026-04 的暴涨（2,003,537 → 2,067,263，+63,726）里，约 5.2 万来自 test262 整体并入 WPT 计数——53,207 个 JS subtest 进入分子分母，真实平台进展约 1.2 万，与 1 月的 +13,690 同一量级。刨掉口径变化，自然增速大约每月一万上下。2025 年 10 月，通过率首次越过全部 WPT subtest 的 90%——官方当时点出这个里程碑的另一层意义：90% 是 Apple 审核 iOS 替代浏览器引擎资格的标准之一。WPT 增长反映 LibWeb 对 HTML/CSS/DOM 的覆盖在推进，但它不能推出「能正常浏览今天的互联网」，因为真实网站还有 quirks、性能要求和未文档化行为，WPT 覆盖不到。

test262 通过率 97.8%（52,045 / 53,207，2026-04 并入 WPT 统计时给出）。这是 ECMAScript 官方一致性套件，仓库里既有 test262 运行器也有专用 CI workflow，是长期跟踪的指标。数字好看有结构原因：这套测试是纯语言行为、边界清晰，LibJS 可以对着规范逐条实现。它说明 JS 语言层和规范咬合得紧；它不能推出「JS 引擎性能好」——一致性是正确性问题，性能是另一回事。

性能数字（Discord 120 FPS、Gmail -1s、Wasm 调用微基准 20x-50x）都是针对特定站点或微基准的 profiling 结果，反映「某个热点被修掉了」，不能推出「整体比 Chrome 快」。月报新增的 Speedometer 2/3 与 StyleBench 是目前唯一的跨站点合成基准口径，但要等 alpha 之后的横向比较，才有参考意义。

采用顺序：谁现在用，谁等一等

• 当研究对象用（不是主力浏览器）：浏览器引擎开发者、Web 标准实现者、安全研究者。Ladybird 把一个完整多进程引擎摊开给你读，进程外解码/网络、Rust 迁移顺序、typed interpreter 都是能直接参考的工程决策。构建步骤在仓库 Documentation/BuildInstructionsLadybird.md，支持 Linux 与 macOS，Windows 走 WSL2（原生构建仍属实验性）。
• 等 alpha 再评估：想在真实产品里评估兼容性的前端开发者。当前是 pre-alpha，FAQ 明确首个 Alpha 面向开发者和早期采用者。2026-08 月报的最新口径：alpha 仍按计划在 2026 年内启动，剩余工作主要在壳层而非引擎——崩溃报告、macOS/Linux 签名安装包、自动更新、首次运行体验（含可选的 EasyList 广告过滤）和下载页面。站点兼容性还在快速变化，现在得出的结论几周后可能过期。
• 普通用户：没有理由现在换过去，等公开 alpha（Linux/macOS）再看。
• 想贡献代码的人：注意治理变化。2026 年 6 月起 Ladybird 关闭了公开 PR，代码只由维护者合入——公告原话是「一个 PR 已经不能像过去那样说明提交者是谁」，叠加浏览器每天处理来自整个互联网的不可信输入，安全面太大。社区贡献现在主要走 bug 报告、最小复现用例、网站测试、标准与设计讨论和安全报告，官方同时明说不会有其他补丁提交渠道。

结尾判断

Ladybird 处于一个微妙的位置：规范符合度足够证明「从零可行」，离「可用」还有距离。它真正的长期价值，是给浏览器生态留一条不依赖任何一家商业公司的路——当三大引擎对 Web 的解释出现分歧时，多一个独立实现，标准就多一份约束。跟踪它，与其盯 star 数，不如盯两个指标：WPT 通过数的自然增速（注意口径变化），以及 alpha 版是否按计划落地。