📌 项目地址：LadybirdBrowser/ladybird | ⭐ 64,920 颗星 | 🔧 C++ | 📜 未标注
📌 项目地址：LadybirdBrowser/ladybird | ⭐ 64,920 | 🔧 C++ | 📜 2-clause BSD
README 里最显眼的位置写着一行警告：项目处于 pre-alpha 状态，只适合开发者使用。这句话没有夸张。用 Ladybird 打开复杂网页，渲染出错是常态而不是意外。
但它有 64,920 颗星。
一个连日常上网都做不到的浏览器，凭什么拿到这个数字？我的答案是：它投给了一个稀缺的东西——一个不基于 Chromium、不基于 WebKit、从零写起的浏览器引擎。
先确认它真的是”独立引擎”
市面上叫自己”独立浏览器”的项目很多，绝大多数只是给 Chromium 换了个界面，内核还是 Google 的代码。判断标准很简单：看它自己实现了什么。Ladybird 的组件清单很长：
- LibWeb：网页渲染引擎
- LibJS：JavaScript 引擎（不是 V8，不是 SpiderMonkey）
- LibWasm：WebAssembly 实现
- LibCrypto/LibTLS：密码学原语和 TLS
- LibHTTP：HTTP/1.1 客户端
- LibGfx：2D 图形、图像解码与渲染
- LibUnicode：Unicode 和区域支持
- LibMedia：音视频播放
- LibCore：事件循环、操作系统抽象层
- LibIPC：进程间通信
从渲染到 JS 到网络到加密，全部自研。这套代码继承自 SerenityOS——一个连操作系统都自己写的项目。README 里明确说，目前许多核心库组件来自 SerenityOS，之后再独立演进。这个出身很重要：代码是一群人在”一切都自己写”的约束下连续写出来的，风格统一，没有拼接感。
多进程架构：安全边界画得很清楚
浏览器处理的输入几乎全部不可信，网页、图片、网络响应都可能是恶意的。Ladybird 的应对是把不同职能塞进不同进程：
- 一个主 UI 进程，只管界面
- 每个标签页一个 WebContent 渲染进程，与系统其余部分隔离（沙箱）
- 一个独立的 ImageDecoder 进程处理图像解码
- 一个独立的 RequestServer 进程处理网络连接
README 的原话说得很直白：图像解码和网络连接放在进程外，是为了更稳健地对抗恶意内容。一张恶意图片攻破的只是解码进程，一个畸形响应攻破的只是网络进程。每个标签页独立渲染再加沙箱，意味着单个页面的沦陷碰不到其他标签页，也碰不到主进程。
代价当然存在：每开一个标签多一个进程，内存和 IPC 开销都大。pre-alpha 阶段跑起来笨重，属于这个架构的固有成本。用资源换隔离，这笔账在安全上是划算的。
对学习者的价值：一个能读完的浏览器引擎
浏览器引擎是软件复杂度天花板级别的领域。Chromium 的代码量以千万行计，一个初学者想搞清楚”从输入 URL 到渲染出像素”的全过程，在那种体量里几个月摸不到头绪。
Ladybird 提供了另一个选项。它规模小得多，但模块完整：事件循环、IPC、HTTP 客户端、JS 引擎、排版渲染、TLS、媒体，一样不缺。也就是说，你可以在可接受的时间跨度里，把一个现代浏览器引擎的核心部分从头读到尾。
而且这是活代码。项目还在 pre-alpha，API 在变，架构在调，issue 里全是正在解决的问题。跟踪它的演进，你看到的是别人怎么做决策，而不只是决策的最终产物。这一点，读任何成熟项目都得不到。
动手前需要知道的事
构建：详见仓库里的 Documentation/BuildInstructionsLadybird.md。支持 Linux、macOS、Windows（WSL2）以及众多 *NIX 系统。没有安装包，需要自己从源码编译。
参与开发：新人先读 Documentation/GettingStartedContributing.md。提 issue 之前必须看 CONTRIBUTING.md 里的 issue policy，以及 ISSUES.md 里的详细报告格式要求。日常讨论在官方 Discord 服务器。
许可证：2-clause BSD。宽松，商用友好，商业公司可以直接拿这套代码，没有授权负担。
我的判断
Ladybird 能不能走到“可日常使用”，没有人能保证。现代 Web 是二十多年规范叠加的产物，一个小团队从零追赶，难度怎么估计都不过分。
但我觉得这个问题不是全部。这个项目现在就提供了三样东西：一份完整的从零实现的浏览器引擎源码，一套画得很干净的多进程安全架构，以及 BSD 许可证下对所有人的开放使用权。对想理解浏览器内部机制的开发者来说，它今天就值得打开。
至于日常上网？等它出 alpha 再说。