2024 年，Ladybird 浏览器项目宣布将 Swift 作为 C++ 的「继任语言」，这一消息在浏览器工程社区引发了广泛讨论。项目负责人 Andreas Kling 当时表示，Swift 的内存安全特性和与现有 C++ 代码的互操作潜力是主要考量。然而，不到两年后的今天，这一雄心勃勃的计划已经悄然搁置 —— 项目网站悄然移除了 Swift 作为继任语言的表述，代码库中仅有极少数 Swift 文件，几乎可以忽略不计。这一技术决策的逆转并非源于单一的技术宣判，而是多个实际因素叠加的结果。本文将从垃圾回收机制、C++ 互操作成熟度、跨平台生态以及项目优先级等多个维度，深入剖析 Ladybird 放弃 Swift 适配的技术根源，并为读者提供在类似浏览器工程场景中选择系统编程语言的可操作参考。
一、Swift 适配计划的起源与愿景
Ladybird 浏览器的诞生本身就是一段独特的技术旅程。作为一个从零构建的独立浏览器引擎项目，它旨在摆脱对 Chromium 或 WebKit 的依赖，为开源社区提供一个全新的选择。在项目启动之初，团队面临着与所有现代浏览器项目相同的基本挑战：如何在保证性能的前提下，逐步摆脱庞大且难以维护的 C++ 代码库。2024 年，随着 Swift 6 即将发布，Ladybird 团队公开评估了多种「C++ 继任语言」，最终选择 Swift 作为潜在的迁移目标。
这一选择的背后有着清晰的技术逻辑。Swift 语言在内存安全方面相较于 C++ 有显著优势，其所有权系统能够在编译期捕获大量内存安全问题，从而减少运行时崩溃和安全漏洞。对于一个需要处理复杂网络内容和高风险输入的浏览器引擎而言，内存安全无疑是核心诉求。此外，Swift 与 C++ 之间的互操作能力也是关键卖点 —— 当时苹果官方承诺将在 Swift 6 中改进与 C++ 的双向互操作，使得渐进式迁移成为可能。团队构想的路线图是：保留现有 C++ 代码不变，逐步使用 Swift 编写新组件，最终实现平滑过渡。
二、垃圾回收机制的根本性冲突
然而，理想与现实之间的差距远比预期更大。最根本的问题在于垃圾回收机制的完全不兼容性。Ladybird 的核心架构围绕自定义垃圾回收系统构建，其 DOM 实现、HTML API 层以及 LibWeb 中的大部分代码都依赖于与 JavaScript 运行时紧密集成的 GC 基础设施。这意味着整个对象生命周期管理、内存分配策略和弱引用处理都针对追踪式垃圾回收进行了深度优化。
Swift 采用的是自动引用计数（ARC）机制，这是一种编译期插入引用计数代码的内存管理策略，而非移动式追踪垃圾回收器。ARC 的优势在于内存管理可预测、延迟低且无需运行时开销，但这也意味着它无法直接适配 Ladybird 架构中那些依赖自定义 GC 对象系统的代码。要在 Swift 中复用这些组件，团队需要构建复杂的桥接层，在 ARC 和追踪式 GC 之间手动管理对象所有权和生命周期。这种桥接不仅增加了工程复杂度，还可能引入微妙的内存管理错误，从而违背了最初选择 Swift 以提升安全性的初衷。
这一技术障碍在 Swift 官方社区中也引发了讨论。Swift 论坛上有专门的线程探讨 Ladybird 的 GC 需求与 Swift 内存模型的适配问题，结论普遍认为即使引入即将推出的 Swift 宏和高级内存管理特性，也难以完全弥合这一架构层面的鸿沟。对于一个以浏览器工程为核心使命的项目而言，在核心基础设施上投入大量精力解决语言层面的适配问题，其性价比显然不足以支撑持续投入。
三、C++ 互操作的实际进展与预期落差
除了内存模型的不匹配，C++ 互操作的成熟度也是决定迁移可行性的关键因素。Ladybird 选择 Swift 的核心论据之一是其宣称的优秀 C++ 互操作能力，然而在实际推进过程中，团队发现官方文档和示例中关于深度 C++ 互操作的内容并未取得实质性进展。对于一个需要与数十万行现有 C++ 代码库交互的浏览器引擎而言，互操作的深度和广度直接决定了迁移的可行性。
具体而言，Swift 与 C++ 的互操作在简单场景下表现良好 —— 可以直接调用 C++ 函数、传递基本类型参数，但在处理复杂的模板代码、STL 容器深度集成、虚函数表交互等场景时，仍存在显著障碍。浏览器引擎中充满了这类复杂交互：DOM 对象的跨语言调用、事件循环的集成、C++ 与 JavaScript 运行时之间的边界处理等。每一处都需要手动编写繁琐的桥接代码，不仅增加了维护负担，也降低了代码的可读性和可移植性。
值得注意的是，社区中关于这一问题的讨论指出，Rust 在 C++ 互操作方面拥有更成熟的工具链和更丰富的实践经验。Rust 与 C++ 的互操作已经得到了广泛验证，数百个开源项目成功使用了 Rust-C++ 绑定方案。这也为后续 Ladybird 社区建议转向 Rust 埋下了伏笔，尽管项目目前尚未做出明确的语言替换决策。
四、跨平台生态与机会成本的双重考量
从更宏观的视角来看，Swift 的跨平台支持也是制约其在浏览器引擎中大规模采用的因素之一。Swift 虽然名义上是开源项目，但其核心主导权仍掌握在苹果公司手中，跨平台支持的首要目标是为苹果生态服务。当前 Swift 对 Linux 的支持主要限于 x86 和 ARM 架构，对于 Ladybird 这类需要支持多种非主流平台的项目而言，这构成了潜在的系统锁定风险。BSD 变体的支持更是处于社区实验阶段，短期内难以进入上游主干。
相比之下，Rust 拥有明确的平台层级支持策略和行业广泛采用的基础设施，从嵌入式系统到服务器端应用都有成熟案例。这种生态成熟度对于一个需要长期维护的浏览器引擎项目而言至关重要 —— 选择一门受制于单一公司战略方向的语言，意味着将项目的部分命运寄托于他人的产品路线图。
与此同时，Ladybird 项目正处于高速发展期，核心团队的精力需要集中在浏览器功能的快速迭代上 ——CSS 布局引擎、Web API 实现、渲染管线优化等工作直接关系到用户能够获得的浏览体验。将有限工程资源投入到一个充满不确定性的语言迁移研究中，意味着延缓用户可见的功能改进，这对于一个处于成长期的开源项目而言是不可接受的取舍。项目团队最终认识到，与其追求语言层面的理想主义改进，不如专注于交付可用的浏览器功能，这一务实的取向直接推动了 Swift 计划的搁置。
五、技术决策的启示与工程实践建议
Ladybird 放弃 Swift 适配的经历为浏览器工程乃至大型系统软件开发提供了宝贵的技术决策参考。首先，语言迁移决策不应仅关注语言本身的特性，还需深入评估目标语言与现有架构的兼容性。内存模型、垃圾回收策略、运行时依赖等底层因素往往比语法糖和类型系统更能决定迁移的成败。当现有系统已经围绕特定运行时特性构建时，强行引入不兼容的内存管理模型将带来巨大的适配成本。
其次，跨平台语言选择需要审视语言的治理结构和生态主导权。Swift 虽然开源，但其发展路径受苹果公司战略深度影响，平台支持的优先级与浏览器引擎的多平台需求之间存在结构性矛盾。而 Rust 作为一门由社区主导的语言，其治理结构和平台策略更具开放性和可预测性，这对于需要长期维护的基础设施项目尤为重要。
最后，对于快速迭代中的项目而言，技术债务的偿还需要在合适的时机进行。Ladybird 团队在评估 Swift 时正值项目从零起步的关键阶段，此时投入资源进行语言层面的探索性研究，其机会成本远高于功能开发。随着项目成熟度和社区规模的扩大，未来或许会有更合适的窗口来重新评估语言策略，但前提是项目首先能够交付可用的浏览器产品。
资料来源
本文主要参考了 GitHub 上 Ladybird 浏览器项目的相关讨论以及 Hacker News 社区的技术分析，相关 Issue 和讨论可见于 https://github.com/LadybirdBrowser/ladybird/issues/5017。