你每天打开的浏览器，本质上只有"一个"。Chrome、Edge、Brave、Vivaldi、Opera——剥掉它们各自花哨的外壳，底下跑的是同一套引擎：Chromium。这不是阴谋论，而是 Andreas Kling 在这场 FUTO 演讲开场就用一张梗图点破的现实："当 Peter 戴上那副眼镜，他看到所有浏览器都是 Chromium。"
这个事实细思极恐。万维网号称是人类历史上最开放、最重要的计算平台，可支撑它的引擎内核却几乎只剩一家公司在维护。如果有一天 Chromium 的方向变了、收费了、或者维护它的人散了，整个互联网的"地基"就会动摇。
这场演讲之所以值得每个软件工程师认真看一遍，不只是因为它讲了一个"理想主义者对抗巨头"的好故事，更因为它把浏览器引擎工程这个软件行业里公认最难的题目，从商业、技术、架构、治理四个维度拆解得清清楚楚。它回答了三个问题:一个浏览器引擎到底复杂在哪里？为什么没人再敢从零写一个？以及——Ladybird 凭什么觉得可以？更妙的是，演讲发布至今的几个月里，这个项目接连抛出两枚"炸弹"（迁 Rust、关 PR），让这个话题在今天看比视频录制时还烫手。
| 项目 | 内容 |
|---|---|
| 视频标题 | Andreas Kling - Ladybird: Building a new browser from scratch |
| 频道/主办方 | FUTO（Andreas Kling 主题演讲） |
| 演讲者 | Andreas Kling（网名 awesomekling，Ladybird Browser Initiative 创始人） |
| 核心主题 | 为何要从零构建一个独立于 Chromium 的浏览器引擎 |
| 演讲者履历 | KHTML（KDE）→ Nokia（Qt WebKit）→ Apple（WebKit/Safari）→ Ladybird |
| 项目语言 | C++（引擎为 LibWeb + LibJS，从零自研） |
| 路线图 | Alpha 2026 / Beta 2027 / 稳定版 2028 |
| 关键战绩 | Web Platform Tests 第 4（仅次 Chrome/Safari/Firefox）；JS 引擎合规度第 2（仅次 SpiderMonkey） |
| ## 核心内容拆解 |
演讲最有杀伤力的画面是一张韦恩图。左边的圆圈是 Google 的引擎（Chromium），右边的圆圈是 Google 的钱。Kling 用它告诉观众：市面上你叫得出名字的"独立"浏览器——Brave、Vivaldi、Edge、Opera——绝大多数都同时落在这两个圆的交集里。它们用 Google 的引擎做地基，又靠把用户的搜索请求导流给 Google 搜索来赚钱。
这就是所谓的浏览器单一文化（browser monoculture）。表面上是五六款产品竞争，本质上是同一个技术内核加上同一条商业血管在循环。Kling 在演讲里说得很直白：这根本不是一个健康的市场，而是一个被单一实体同时掌握技术标准和资金来源的生态。当引擎、标准、钱都流向同一个方向时，"多样性"就成了营销话术。（注：以上韦恩图与比喻为演讲原话，对单一文化危害的判断则是我与多数标准倡导者的共识延伸。）
这段是全演讲最反直觉、也最清醒的工程洞察。Kling 给出了三组数字来丈量这个产业的体量：Google 每年大约花 20 亿美元维护 Chrome 浏览器；每年向 Apple 支付约 200 亿美元，只为让 Google 成为 Safari 的默认搜索引擎；每年给 Mozilla 约 5 亿美元，买下 Firefox 的默认搜索位。
然后他说了一段堪称经典的话（演讲原话）："如果你给软件工程团队几百万甚至几十亿美元，会发生什么？我可以告诉你——他们会雇几百个工程师，然后这几百个工程师会写出几千万行代码。因为事情就是这样发展的。从来没有人雇了 200 个工程师，最后只得到一个一万行的项目。" 而几千万行代码，又需要几百个工程师去维护和继续开发。
这就是 Kling 给出的真正答案——为什么没人再敢从零写浏览器？不是技术做不到，而是这个体量的代码一旦写出来，就形成了自我维持的引力场：要养它就需要大钱，要赚大钱就离不开广告和搜索分成，离不开搜索分成就只能继续依附。一个完美的负反馈闭环，把整个生态锁死。Kling 一句话总结："我们现在被困住了。"（we are now trapped）这段论述是演讲原话，"绞肉机""引力场"的概括是我的转译。
为什么这个"题"会难到值 20 亿美元一年？我把演讲里点到、以及工程界公认的因素拆开来看，一个现代浏览器引擎至少要啃下六块硬骨头：
Kling 在演讲里点出 Ladybird 截至 2025 年 3 月在 WPT 排第 4、JS 引擎合规第 2，这两个数字本身就是"从零写"含金量的最好证明——一个 2019 年才起步、团队规模远小于巨头的项目，硬是爬到了独立引擎能企及的高度。（合规排名为公开事实，"六块硬骨头"的归纳是我结合工程常识的整理。）
技术项目的故事往往比代码更动人。Kling 在开场介绍自己是个"一辈子的浏览器书呆子（lifelong browser nerd）"，并亮出他二十年接触过的引擎清单：2005 年从 KDE 的 KHTML 起步（KHTML 正是后来 WebKit 的祖先），接着在 Nokia 做 Qt WebKit，再到 Apple 做 WebKit 和 Safari，2019 年起做 Ladybird。
但这段履历之外还有一条更动人的暗线。在他的个人主页上，Kling 写过自己的经历：瑞典人，曾是药物成瘾者，在康复过程中开始写 SerenityOS——一个从零打造的类 Unix 操作系统——作为重建生活秩序的方式。SerenityOS 不只是练手项目，它沉淀出一整套以 Lib 为前缀的自研库：LibWeb、LibJS、LibHTTP、LibWasm……而 Ladybird，正是从 SerenityOS 的这套库里孵化、最终独立出来的浏览器。（个人经历细节来自 Kling 公开主页与社区资料，非演讲全部覆盖；这条"用写代码来自我疗愈"的叙事是我认为最值得讲给同行听的部分。）
2024 年 6 月 30 日，Kling 宣布退出 SerenityOS，全力投入 Ladybird。一个浏览器老兵，带着救赎式的人生动力，向整个行业最难的山头发起冲锋——这是这个项目最有说服力的"为什么"。
Ladybird 最硬核的标签是"from scratch"——从零写。它不用 Chromium，也不用 Firefox 的 Gecko，连 JavaScript 引擎都是自研的 LibJS，而不是套用 V8 或 SpiderMonkey。这在 2020 年代几乎是"反常识"的工程选择，因为复用成熟引擎明明省力得多。
Kling 的逻辑（演讲与项目文档综合）是：只有自己掌握从解析到 JS 的每一行代码，才能真正摆脱被巨头牵着走的命运。Ladybird 用 C++ 编写，采用 BSD 2-Clause 许可证，整套代码刻意保持"精简、可 hack"——这点和 Chromium 几千万行的体量形成鲜明对照。这种"小而自洽"的工程美学，本质上是把要点二里那个"代码绞肉机"反过来用：用更小的代码、更少的依赖，换取更低的维护成本和更高的可理解性。
需要补充一个对工程师很有启发的设计：Ladybird 没有把自己绑死在某个语言或某个 OS 上。它最初依赖 SerenityOS 的库，但独立后逐步引入其他开源库，并保持跨平台（macOS、Linux）。这种"自研核心 + 开放生态"的混合策略，是从零造系统时务实与理想之间的精妙平衡。（语言/许可/架构为公开事实；"小代码反制大代码陷阱"是我的分析。）
光有一个引擎还不够，现代浏览器的命门是安全与稳定。一个标签页崩溃不能拖垮整个浏览器，一段恶意 JS 不能轻易越权。Ladybird 的解法是多进程架构（multi-process architecture）：把渲染、JavaScript 执行、网络等职责拆进不同进程，进程之间用 IPC（进程间通信） 协作，并用沙箱做隔离。
这其实是 Chrome 当年确立的工程范式——每个站点隔离（site isolation）——但 Ladybird 用自己的方式重新实现了一遍。对一个从零写的项目而言，这意味着团队要在"造引擎"之外，再同时造一套可靠的 IPC 机制和进程模型。这也解释了为什么浏览器工程如此消耗人力：你几乎是在造一个"操作系统之上的操作系统"。多进程 + IPC 是公开的架构事实，"浏览器是 OS 之上的 OS"的判断是我的概括，也是业内的常见说法。
技术之外，这场演讲最与众不同的部分是 Ladybird 的商业模式——准确说是"反商业模式"。它注册为非营利组织 Ladybird Browser Initiative，明确承诺不追踪用户、不靠广告变现，资金全部来自捐赠和企业赞助。
赞助名单相当亮眼：GitHub 联合创始人 Chris Wanstrath 在 2024 年 7 月宣布个人资助；Cloudflare、FUTO、Shopify、37signals、Proton VPN 等也先后加入。Kling 的逻辑链是自洽的：要点二里那个"依附搜索分成"的死结，根源就是浏览器要赚钱；既然 Ladybird 不打算从用户身上赚钱，它就可以彻底脱离那条资金链，从而获得真正的技术独立。
对软件行业而言，这是一种值得研究的"公共物品（public good）"融资范式——把一个基础设施级软件当图书馆、当公路来用赞助维持，而不是当收割用户的流量入口。它能不能长期跑通，目前还是开放问题，但 Ladybird 至少提供了一个真实在跑的样本。（融资方与模式为公开事实；"公共物品融资范式"是我的延伸分析。）
演讲本身已经足够精彩，但项目在演讲之后的两个动作，让这个话题在今天看格外值得分析，这也是我作为解读者要额外补上的"增量"：
第一枚：2026 年 2 月，Ladybird 开始把 JavaScript 解析器和字节码生成器从 C++ 迁移到 Rust。 更有意思的是，开发者借助了 Claude Code 和 OpenAI Codex 这样的 AI 编程助手来完成迁移。这件事有两层信号：一是 Rust 在"内存安全敏感、性能又要求高"的子系统（JS 引擎正是典型）里继续蚕食 C++ 地盘；二是连最硬核的从零造引擎项目，也已经把 AI 编程助手当成熟练工具用进日常开发。这与本系列此前讨论过的"AI 改变编程"主题形成呼应。
第二枚：2026 年 6 月 5 日——距离今天仅 11 天——Ladybird 宣布不再接受外部公开 PR，也关闭其他非维护者提交补丁的渠道。 官方理由是：随着首个 Alpha 临近，外部贡献质量参差，且需要更严格地把控安全。这是一个大胆到近乎"叛逆"的决定。在开源世界里，"闭门开发"几乎等于异端——大多数项目巴不得更多人贡献代码。但 Ladybird 选择在关键冲刺期收紧权限，用可控性换质量。
我的判断是：这两件事其实指向同一个工程哲学——在冲刺 Alpha 的关键阶段，Ladybird 优先要的是"对每一行代码的可控"，而不是"代码的数量"。这恰恰呼应了 Kling 在演讲里对"代码绞肉机"的批判：宁可慢一点、人少一点，也不要重蹈"千万行代码、几百人维护"的覆辙。一个从零造引擎的项目，最怕的就是在半成品阶段被低质量代码稀释。从这个角度看，关闭 PR 不是退缩，而是为保住"独立"这个核心竞争力所做的防御性收缩。（这两条均为 2026 年最新公开事实，分析与 Kling 演讲逻辑的关联是我的推断。）
flowchart TD
A["浏览器单一文化问题<br/>所有浏览器≈Chromium"] --> B["韦恩图真相<br/>左:Google引擎 / 右:Google钱"]
B --> C["资金闭环绞肉机<br/>200工程师→千万行代码→需更多人→需更多钱"]
C --> D{"Kling 的回答:<br/>从零造一个不依附的引擎"}
D --> E["技术层:from scratch"]
E --> E1["LibWeb<br/>HTML/CSS解析+布局+渲染"]
E --> E2["LibJS<br/>自研JS引擎 合规第2"]
E --> E3["多进程+IPC+沙箱<br/>安全与稳定"]
E --> E4["C++ → 部分迁Rust<br/>(2026.2 AI辅助)"]
D --> F["商业层:非营利"]
F --> F1["Ladybird Browser Initiative<br/>不追踪/不广告"]
F --> F2["赞助:Wanstrath/Shopify/<br/>FUTO/37signals/Cloudflare"]
D --> G["治理层:可控优先"]
G --> G1["2026.6.5 关闭外部PR<br/>冲刺Alpha/严控安全"]
E3 & F2 & G1 --> H["目标:真正独立的Web引擎<br/>Alpha2026 / Beta2027 / 稳定2028"]
如果你是后端/系统工程师，这场演讲给你最值钱的启发不是"也去造浏览器"，而是 Kling 对代码体量与维护成本的清醒认知。那句"从来没人雇 200 个工程师只得到一万行项目"应当贴在每个技术负责人的墙上。它提醒你：团队规模和代码行数一旦失控膨胀，就会形成自我维持的"引力场"，把组织拖进"为了养这些代码而不得不继续做大"的陷阱。Ladybird 刻意保持"精简、可 hack"的代码库，本质上是一种主动的反膨胀工程——在自己的项目里，你同样可以问：这一万行新增代码，未来要多少人维护？值不值？
如果你是前端/Web 开发者，这个视频帮你建立对"浏览器"这个工作环境的底层敬畏。你写的每一行 HTML/CSS/JS，最终要被解析、布局、JIT、合成、沙箱化——背后是 20 亿美元一年养出来的巨型机器。理解 LibWeb/LibJS 这类引擎的分层，能让你在排查跨浏览器兼容问题、性能瓶颈、布局抖动时，从"猜"升级到"知道引擎在哪一层出了问题"。Ladybird 在 Web Platform Tests 上从零爬到第 4，也说明 WPT 这套测试体系是理解 Web 标准合规性的最佳抓手，值得作为进阶学习地图。
如果你关注开源治理与商业模式，Ladybird 提供了一个罕见的活样本：如何用非营利 + 企业赞助的方式，为一个"公共物品"级软件长期供血，而不靠收割用户。2026 年 6 月关闭外部 PR 的决定，更是给所有开源维护者上了一课——贡献者数量不是越多越好，代码可控性才是基础设施级项目的生命线。当你自己的开源项目即将进入"被依赖"阶段时，这套"可控优先于开放"的取舍值得认真参考。
对所有人，这个故事最大的力量在于：在一个人人都觉得"造浏览器不可能"的年代，一个康复中的老兵带着小团队，用"从零写、不依附"的方式，硬是逼近了 Alpha。它证明了一件事——软件工程里那些"已经被巨头锁死、再无可能"的领域，往往只是缺一个愿意从第一行代码重新开始的人。
Ladybird 用"从零写、不依附、非营利"的三重抗命，向软件行业最难的山头发起冲锋，也顺手回答了一个更深的命题——真正困住技术进步的往往不是能力，而是规模与金钱形成的代码引力场。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
51xtx-ppt-writer 或 chart-craft 将 Mermaid 知识结构图转为精美 PNG[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。