Ladybird：从零造浏览器引擎的野心与现实
核心观点
Ladybird 是目前唯一一个真正从零构建渲染引擎的浏览器项目，不继承 Blink、Gecko、WebKit 任何一行代码。这在 2024–2026 年的浏览器生态中是一件罕见事：几乎所有"新浏览器"都是套壳 Chromium，而 Ladybird 是一场对"浏览器引擎同质化"趋势的正面反抗。
但必须说清楚它处于哪个阶段——pre-alpha，Alpha 版本预计 2026 年才发布（仅支持 Linux 和 macOS），目前仅适合开发者使用。这不是一个你能拿来替代 Chrome 的工具，而是一个工程意志的宣言。
技术机制：最关键的那个设计决定
Ladybird 最巧妙的地方不是"从零写引擎"本身，而是它继承了 SerenityOS 的多年积累，再走出来独立生长。它的核心库均源自 SerenityOS 项目：
| 库 | 职责 |
|---|---|
| LibWeb | HTML/CSS 渲染引擎（相当于 Blink） |
| LibJS | 自研 JavaScript 引擎（相当于 V8，但远不及） |
| LibWasm | WebAssembly 执行 |
| LibCrypto/LibTLS | 加密与 TLS |
| LibGfx | 2D 图形、图像解码 |
| LibUnicode | Unicode 与本地化 |
| LibMedia | 音视频播放 |
| LibIPC | 进程间通信 |
关键机制在于它的多进程沙箱架构：
- 主 UI 进程（一个）
- 每个 Tab 独享一个 WebContent 渲染进程，并被沙箱隔离
- 独立的 ImageDecoder 进程和 RequestServer 进程
这与 Chrome 的多进程架构理念一致——将图像解码、网络连接隔离到独立进程，使恶意内容无法直接攻击主进程。这是现代浏览器安全架构的标准做法，Ladybird 一开始就选对了方向，而不是走"先单进程后重构"的老路。
另一个重要的技术转向：官方确认正在逐步引入 Rust 替代 C++，CSS 布局和样式系统已经开始向 Rust 迁移，这与 Firefox/Servo 的路径如出一辙。
历史脉络对比：它比之前的方案好在哪？
把 Ladybird 放入浏览器生态的历史来看：
- 2016 年后：浏览器引擎进入寡头时代。Edge 抛弃 EdgeHTML 投奔 Blink，Opera 早已沦为壳，Brave/Vivaldi/Arc 全是 Chromium 套壳。实质上只剩 Blink、Gecko、WebKit 三棵树。
- Safari/WebKit：苹果封闭，iOS 上强制所有浏览器使用 WebKit，选择权被剥夺。
- Firefox/Gecko：是目前唯一有竞争力的独立引擎，但背后 Mozilla 的商业模式（依赖 Google 搜索分成）造成内在矛盾——Firefox 存活靠的是它最大竞争对手的输血。
Ladybird 的差异化不是功能更强，而是：
- 没有利益冲突：纯捐赠驱动，Shopify、Cloudflare、Proton VPN、FUTO、JetBrains 等均为无附加条件的赞助，不影响技术路线；
- 无历史包袱：不带几十年的技术债，可以直接按最新 Web 标准实现，而不是在旧代码上打补丁；
- 牺牲：没有现成用户基础，兼容性需要从零积累，性能暂时与主流引擎差距极大。
推演：接下来会怎样
我的判断是：Ladybird 最危险的阶段不是现在，而是 2027–2029 年。
原因如下：
兼容性墙：现代 Web 应用（Google Docs、Figma、各类 SPA）大量依赖引擎的细节行为，即使 LibJS 和 LibWeb 完全按标准实现，真实网站依然会"按 Chrome 行为"而非"按标准"运作。这个"追标准但追不上现实"的问题，Firefox 花了十几年才勉强解决，Ladybird 的团队更小。
Rust 迁移是双刃剑：引入 Rust 能提升安全性，但也意味着核心组件要重写，工程量成倍增加。好处是，一旦完成，安全性叙事会非常有力。
资金模型是关键变量：GitHub 联合创始人 Chris Wanstrath 捐赠了 100 万美元，Shopify 也有支持。官方策略是维持 18 个月的资金储备。这个模式短期内可行，但若 2026 年 Alpha 发布后用户反馈一般，持续赞助的积极性会受考验。
边界：不要被"独立"光环遮蔽
几个被过度夸大或被忽视的问题，必须正视：
- "independent"是工程独立，不是生态独立：Ladybird 仍然运行在 Linux/macOS 之上，依赖系统字体、音频、图形栈。它的"独立"指的是渲染引擎层的独立，而不是脱离整个软件生态。
- LibJS 与 V8 的差距是鸿沟级别的：Google 在 V8 上投入了数十亿美元和数百工程师年，LibJS 目前能正确运行 ECMAScript 规范测试集，但现实 Web 应用的 JS 性能将是长期短板。
- 不适合普通用户：明确标注 pre-alpha，只适合开发者。在 2026 年 Alpha 之前，不要向非技术用户推荐。
- Windows 支持不完整：目前只能通过 WSL2 运行，原生 Windows 支持在路线图上但非优先项。
- 移动端无计划：Android/iOS 明确不在当前阶段，而移动端才是现在流量最大的战场。
交叉验证
搜索到两个独立信源对原文核心观点进行了验证与补充：
1. Ladybird 官网（ladybird.org，官方信源，2026年持续更新）
认同原文"pre-alpha、面向开发者"的定位，补充了原文未提到的重要信息：技术栈已从"纯 C++"转向"C++ 逐步向 Rust 过渡"，CSS 布局和样式模块正在向 Rust 迁移；2026年7月更新包含私人浏览、地理位置、WebAudio 等功能。这说明项目进展比原始 README 描述的更为积极，Rust 迁移是一个重要变量，原文 README 未体现。
2. CSDN 深度分析文章（作者：Rthan，2026年5月）
独立作者从技术架构层面做了详细拆解，与原文观点高度一致，但额外指出：目前 Ladybird 的 UI 层基于Qt6构建（原文 README 未提及），并明确点出"性能优化"与"网页兼容性"是两大核心瓶颈，作者的质疑句——"2026 年新引擎最难攻克的是性能还是兼容性？"——是一个有价值的开放问题，反驳了部分过度乐观的叙事。
两个信源均无明显反驳，但都在补强原文 README 过于简洁的描述，尤其是关于现实局限性的部分。
个人启发
对于不同身份的读者，这个项目的价值截然不同：
- 浏览器引擎开发者 / 学习者：这是目前最适合学习浏览器内部原理的现役开源项目之一。代码现代（C++20/23 + Rust），架构清晰，没有 Chromium 那种令人生畏的历史包袱。如果你想学习 HTML 解析、CSS 布局、JS 引擎，直接看 LibWeb/LibJS 的代码比看任何教材都直接。
- Web 标准关注者：Ladybird 的每一个实现都在逼迫自己严格按规范来，发现的每一个标准模糊地带都会促进 Web 规范本身的完善，这对 Web 生态是实质贡献。
- 浏览器产品决策者：现在不需要做任何迁移决策，但值得把 Ladybird 加入 2027 年的技术雷达。一旦它通过 Acid 测试、WPT 兼容性提升到 85% 以上，就到了需要认真评估的时间点。
- 隐私/安全工具链建设者：Proton VPN、Human Rights Foundation 等赞助商的加入说明隐私社区对 Ladybird 的期待。如果你在构建安全浏览环境（企业内网、隐私工具箱），Ladybird 的沙箱架构+无商业利益模型是值得关注的方向。
具体可操作的动作：在 Linux/macOS 开发机上按照官方文档编译一次，把它跑起来，在里面打开几个你常用的网站，看哪些坏了——提交一个 issue 或 bug reduction，这比读十篇分析文章更有价值。
延伸思考
Web 标准的"事实标准"悖论：Ladybird 严格按 W3C/WHATWG 规范实现，但 Web 开发者长期以 Chrome 行为为准，很多主流网站的代码实际上依赖 Blink 的非标准行为。当 Ladybird 按规范运行时反而显示异常——这暴露了一个深层问题：Web 标准文档与真实 Web 之间存在多大的裂缝？这条裂缝是否会永久阻止任何新引擎的兼容性追赶？
"从零写一切"与"站在巨人肩膀上"的工程哲学之争：Ladybird 最初甚至连第三方图像解码库都不用（SerenityOS 传统），后来才改为使用外部库。这次妥协是务实的选择还是信仰的败退？在基础设施层面，什么时候应该造轮子、什么时候应该复用？
独立浏览器的商业模式能否持续：Brave 的模式是发行加密货币，Firefox 靠 Google 分成，Ladybird 靠纯捐赠。随着项目团队扩张、工程量加大，纯捐赠能否支撑一个完整引擎的长期维护？还是说 Ladybird 最终会走向某种商业妥协，或成为另一个"开源精神旗帜，现实中鲜有人用"的项目？
📚 参考来源
- GitHub - LadybirdBrowser/ladybird: Truly independent web browser · GitHub
