在一个由少数科技巨头主导的世界里，从零开始构建一个全新的网络浏览器，是一项近乎于挑战神明的举动。
然而，这正是 Ladybird 浏览器项目正在做的事情。它并非简单地为现有技术换上一层新的外壳，而是致力于打造一个真正独立的网络浏览器，其核心包含一个全新的引擎（LibWeb）和一个自研的 JavaScript 解释器（LibJS）。
所以，今天这篇文章，我们就来讲讲，浏览器内核究竟是个什么东西，它为何没有天女散花般非常的多。以及，当 Chrome 被收购后，会发生什么事情？
当然我是 Safari 和 FireFox 爱好者，Chrome 只是拿来当作话题的东西。
心脏#
对于大多数用户而言，浏览器就是屏幕上的那个图标，是通往广阔互联网的大门。
但在这扇门的背后，真正发挥核心作用的是一个被称为浏览器内核（Browser Engine）的复杂软件组件。我们可以用几个简单的比喻来理解它。
它是浏览器的心脏，不知疲倦地泵送着数据，它也是一位伟大的翻译官，将网站的原始代码，也就是那些由 HTML、CSS 和 JavaScript 组成的、人类难以直接阅读的文本，实时翻译成我们在屏幕上看到的、可交互的、生动丰富的网页。
浏览器内核、布局引擎（Layout Engine）和渲染引擎（Rendering Engine）这几个词经常被使用。
它们共同描述了浏览器的核心部分，其主要职责是解释网页代码，计算出页面上每一个元素的位置和样式（即“布局”），然后将它们绘制到屏幕上。
为了更清晰地理解浏览器的结构，我们需要将浏览器内核与另外两个部分区分开来：一是用户界面（UI），这包括了我们能直接看到的地址栏、前进后退按钮、标签页等。
一是JavaScript 引擎（JavaScript Engine），这是一个独立的组件，专门负责执行网页中的 JavaScript 代码，赋予网页动态交互的能力。
浏览器内核负责协调这一切，它与 JavaScript 引擎紧密合作，共同将静态的文档变为一个活生生的应用。
历史#
纵观现代互联网，几乎所有的网络体验都由三个主要的浏览器内核家族所驱动。
它们是技术演进和市场竞争的产物，每一个都代表着一条独特的进化路径：
- Blink：由谷歌主导开发，于 2013 年从 WebKit 项目中分支（fork）而来。它是当今世界上市占率最高的内核，驱动着 Chrome、微软的 Edge、Opera、Brave、Vivaldi 等众多浏览器。
- WebKit：由苹果主导开发，其历史可以追溯到更早的 KHTML 引擎。WebKit 是 Safari 浏览器的核心。在 Blink 诞生之前，它也曾是 Chrome 浏览器的内核。
- Gecko：由 Mozilla 基金会开发，是 Firefox 浏览器的核心。在 Blink/WebKit 体系之外，Gecko 是目前唯一一个仍然保持着显著市场份额和影响力的独立内核。
此外，我们不应忘记那些曾经的参与者，例如微软的 Trident（用于 Internet Explorer）和 EdgeHTML（用于旧版 Edge 浏览器）。
（Blink 内核是 Chromium 开源项目的一部分）
奇迹#
输入URL#
一切始于一个简单动作，在地址栏输入一个网址（URL）并按下回车。
浏览器接收到这个指令后，其内置的网络组件立即开始工作。
这个过程大致可以分为几步：
- DNS 查询：浏览器首先需要知道这个网址对应的服务器在哪里。它会查询“域名系统”（DNS），这个系统就像是互联网的“电话簿”，能将我们容易记忆的域名（如 www.baidu.com）翻译成服务器能够理解的 ↗ IP 地址（如 220.181.7.203）。
- 建立连接：获得 IP 地址后，浏览器会通过 TCP 协议与目标服务器建立一个可靠的连接。
- 发送请求：连接建立后，浏览器会代表用户向服务器发送一个 HTTP 请求，请求获取该网址对应的网页内容。
DOM 和 CSSOM#
服务器收到请求后，会返回相应的数据，通常最先到达的是一个 HTML 文件。
此时，渲染引擎开始执行解析（Parsing）。
首先，引擎会逐行读取 HTML 代码，并将其转换成一个计算机能够理解的、树状的逻辑结构，这个结构被称为文档对象模型（Document Object Model, DOM）。
这个过程好比是将建筑师的平面设计图，转化为一份包含所有房间、墙壁、门窗及其相互关系的结构化清单。
其次，在解析 HTML 的同时，浏览器也会请求并解析 HTML 中引用的 CSS 文件。它会把所有的样式规则（如颜色、字体大小、布局方式）同样转换成一个树状结构，称为 CSS 对象模型（CSS Object Model, CSSOM）。
渲染树#
接下来，引擎会将 DOM 树和 CSSOM 树结合起来，创建一棵新的树，渲染树（Render Tree）。
这棵树是页面最终视觉呈现的总规划图。它非常智能，只包含那些需要被实际显示在屏幕上的元素。
例如，一个在 CSS 中被设置为 display: none 的元素，就不会出现在渲染树中，渲染树中的每一个节点，都包含了它最终的样式信息。
万物归位#
渲染树构建完成后，就进入了至关重要的一步：布局（Layout），有时也称为重排（Reflow）。
在这一阶段，引擎会精确计算出渲染树中每一个节点在屏幕上的几何信息，即它的尺寸和位置。
从整个页面的宽度，到某个按钮的高度，再到一行文字应该在哪里换行，所有这些空间关系都在这一步被精确到像素的计算出来。
绘制#
当所有元素的位置和大小都已确定，引擎终于可以开始绘制（Painting）了。
它会遍历渲染树，并调用操作系统的图形接口（UI 后端），将每一个元素，文字、图片、背景色、边框等，绘制到屏幕的对应像素上。
值得注意的是，整个过程是渐进式的。为了提供更好的用户体验，浏览器会尽可能早地开始绘制内容，而不是等到所有 HTML、CSS 和图片都下载完毕。
这就是为什么我们有时会看到页面内容先出现，然后样式才加载进来，导致页面闪烁一下（即无样式内容闪烁，Flash of Unstyled Content）。
交互#
当页面被初步绘制出来后，独立的 JavaScript 引擎（例如 Chromium 中的 V8 引擎）便开始大显身手。
它负责执行页面中嵌入的 JavaScript 代码，为原本静态的页面注入活力。
无论是点击按钮后的弹窗、页面的平滑滚动动画，还是无需刷新页面就能加载新内容（AJAX），都是 JavaScript 的功劳。
这个过程也揭示了性能优化的关键。所有这些操作，从布局、绘制、到 JavaScript 执行，通常都发生在同一个主线程上。
如果一段 JavaScript 代码执行时间过长，就会阻塞主线程，导致浏览器无法响应用户的滚动、点击等操作，页面就会出现卡顿，即使用户看到的内容已经完全加载。
这正是浏览器开发者们在性能优化方面持续投入巨大精力的原因。
谷歌 vs 美国#
既然讲到了 Chrome，那么就顺便讲讲反垄断这个事情吧，简单来说，联邦法官阿米特·梅塔（Amit Mehta）于 2024 年 8 月裁定，谷歌通过非法手段维持了其在通用搜索服务和搜索广告市场的垄断地位。
例如谷歌仅在 2021 年就支付了高达 263 亿美元，以确保其搜索引擎成为各大平台上的默认选项。
在此判决之后，司法部提出了旨在瓦解该垄断的系列补救措施，其中最引人注目的核心要求便是强制谷歌剥离其 Chrome 浏览器业务。
作为市场份额绝对领先的浏览器，Chrome 是谷歌维持其搜索垄断的关键工具。它不仅是触达数十亿用户的最重要分发渠道，还是一个规模庞大的数据收集终端，进一步巩固了谷歌在搜索领域的护城河。
（注意，司法部的剥离令针对的是 Google Chrome**）**
公共工程#
那么问题来了，在被迫出售其旗舰浏览器产品后，谷歌是否还有动机继续对 Chromium 项目进行巨额投资？
答案是肯定的，因为谷歌的核心商业利益与开放网络的健康发展已密不可分。
谷歌的主要收入来源，搜索广告、YouTube 和谷歌云服务，无一不依赖于一个快速、稳定、安全且不断创新的网络平台。
一个停滞不前或碎片化的网络，将直接损害谷歌通过内容和服务变现的能力。
因此，资助 Chromium 不仅仅是为了支持一个浏览器产品，更是为了维护其价值数万亿美元生态系统的基础架构。
与此同时，谷歌可以继续引导网络标准，确保网络平台向着有利于其先进广告技术、富媒体内容和复杂网络应用的方向演进。
当然，防止像苹果（拥有 WebKit 引擎）这样的竞争对手主导网络标准的发展方向，从而避免其核心服务在未来的网络环境中处于不利地位，也是谷歌的目的。
因此，可以将 Chromium 视为谷歌的一项战略性护城河，而非仅仅是其某个产品的依赖项。
司法部的补救措施旨在拆除 Chrome 这个用于巩固搜索垄断的产品，但谷歌的商业模式本身依赖于整个开放网络平台的健康。
塑造这个平台的关键力量正是 Chromium 的 Blink 引擎。因此，即使失去了 Chrome 产品，谷歌通过投资 Chromium 来影响网络平台演进的动机依然存在。
这已不再是为了一个被剥离的产品，而是为了保护其核心收入流免受平台级风险（例如，网络演进方向被苹果主导，或变得过于碎片化而难以有效变现）的战略投资。
对 Chromium 的资助，是谷歌为维护其商业帝国根基而必须承担的公共工程开销。
那么，剥夺 Chrome 真的反垄断了吗？
维护成本#
维护 Chrome 及其基础 Chromium 项目是一项规模宏大的工程，其成本和复杂性堪比开发一个完整的操作系统。
这里我们暂时跳过对 Chromium 开发的问题，留到之后讲 Ladybird 的时候再说。我们先来聊聊 Chrome 的安全问题。
安全保障依赖于快速响应。Chrome 大约每 4 到 6 周发布一次完整的浏览器更新，而包含关键安全修复的次要更新则每 2 到 3 周发布一次。
几乎每一次更新都包含安全补丁，且所有补丁都应被视为同等重要。这种高强度的更新节奏需要一支庞大、专业的安全与发布工程团队。
换句话说，像 OpenAI 和 Perplexity 这样的 Chrome 潜在买家，虽然估值高达数百亿甚至数千亿美元，但它们自身也在为核心的 AI 业务，消耗数十亿美元的现金。
这些公司的核心竞争力在于大型语言模型，而非为拥有数十亿终端的客户端应用管理一个全球性的安全基础设施。
因此，安全负担本身就成为一个巨大的、非显性的壁垒。收购方买下的不只是一个庞大的用户群，更是继承了一场需要永久投入的网络战争。
这极大地限制了合格候选者的范围，甚至让人们对剥离方案本身的可行性产生了疑问。
（所有因谷歌向 Chrome 投入的安全奖励等，Chromium 都属于间接受益者）
除此之外，司法部的目标是，“将市场从反竞争行为中解放出来并恢复竞争”。法院认定的损害在于谷歌利用其主导性资产（Chrome）来保护另一个主导性资产（搜索）。
然而，若将 Chrome 出售给像 OpenAI 这样资金雄厚的实体，很可能并不能解决根本性的反垄断问题，而只是将其转移到下一个技术范式中。
OpenAI 收购 Chrome 将完美复制谷歌的模式：利用一个市场主导的资产（Chrome）来巩固其在人工智能代理和 AI 驱动信息检索这一新兴且可能更为关键市场中的领先地位。
这就产生了一个垄断悖论，为解决一个垄断而采取的补救措施，却直接为下一个垄断的形成播下了种子。监管机构可能只是解决了昨天的问题，却创造了明天的问题。
因为任何一个拥有 Chrome 市场力量的竞争者，都可以轻易地使其 AI 服务成为互联网的默认入口，这与拆分谷歌的初衷背道而驰，并未解决垄断的实质性问题。
基金会#
面对企业出售可能带来的种种弊端，一个更具建设性的替代方案浮出水面。将 Chromium 项目置于一个中立的、非营利性基金会的管理之下。
该方式被广泛认为是确保 Chromium 作为关键网络基础设施能够持续健康、中立发展的最佳途径。
基金会的运作可以效仿 Linux 基金会或 Apache 软件基金会等成功的开源组织。
治理权将由包括谷歌、微软、Opera 等依赖 Chromium 生态系统的主要利益相关方共同分享。
而基金会的运营资金将由依赖该生态系统的成员组成的联盟共同提供。这种模式分散了财务负担，并能有效防止任何单一公司施加不当影响。
以上内容只是简单的蹭个热点，这一篇文章还是给大家介绍 Ladybird
Ladybird#
Ladybird 的起源可追溯至 SerenityOS 项目，这是一个完全从零开始构建的爱好者桌面操作系统。
最初，Ladybird 仅是该系统内一个功能简单的 HTML 查看器。这段历史对其后续发展至关重要，因为它奠定了项目第一性原理的开发文化，即不依赖现有框架，而是通过直接实现基础规范来构建系统。
项目的关键转折点是其创始人 Andreas Kling 的决定，他宣布从 SerenityOS 的日常维护中退出，将全部精力投入到 Ladybird 的开发中，并将其从 SerenityOS 中分支出来，成为一个独立的、支持跨平台的项目。
为了确保项目的长期独立性和使命驱动，团队正式成立了 Ladybird 浏览器倡议（Ladybird Browser Initiative），这是一个在美国注册的非营利组织。
这一组织形式从法律上确立了其公共利益属性，而非商业盈利目标。
透明#
Ladybird 的核心开发哲学是严格的网络标准优先方法。开发团队直接依据万维网联盟（W3C）和网页超文本应用技术工作组（WHATWG）等标准组织发布的规范文档来从头实现各项功能。
这种做法与当前由市场主导者通过其浏览器实现来事实性定义标准的模式形成了鲜明对比。
项目致力于完全的透明度，其所有开发活动均在GitHub 上公开进行，社区的主要沟通则通过 Discord 服务器完成，任何人都可以参与讨论和贡献代码。
此外，项目将用户隐私置于核心地位。其发展规划中包含了内置的广告拦截功能，并明确拒绝任何形式的用户追踪和数据变现方案。
经济#
Ladybird 的项目资金完全来源于个人和企业的无条件捐赠与赞助，这一模式与主流浏览器的商业模式截然不同。
当前大多数浏览器，包括开源的 Firefox，其主要收入来源于与搜索引擎签订的默认搜索引擎协议。（详见上文）
Ladybird 的非营利、纯捐赠模式并不仅仅是一种另类的筹资策略，更是其技术和伦理独立性的结构性保障。
主流浏览器如 Firefox 的主要收入来源是搜索引擎的合作费用，这在财务上形成了一种强大的激励，使其在决策时必须考虑搜索引擎提供商的目标。
这些目标通常涉及用户数据收集以支持广告业务，这与保护用户隐私的初衷可能存在冲突。
Ladybird 通过其组织章程和公开承诺，从制度上切断了这一收入来源。通过在组织层面消除这种潜在的利益冲突，项目确保其技术决策（例如，实现更强的隐私保护功能、默认拦截追踪器）永远不会因为需要取悦财务合作伙伴而受到影响。
因此，其经济模式是其用户中心理念得以实现的坚实基础。
功能#
当然，我们也得回到现实，Ladybird 它好用嘛？
Pre-Alpha#
目前，Ladybird 仍处于预 Alpha 开发阶段，尚不适合普通用户日常使用。
想要体验该浏览器的用户必须从源代码自行编译，这对于水友们来说虽然不难，但对普通大众还是有较高门槛的。
尽管如此，项目保持着活跃且快速的开发节奏，团队通过发布月度进展视频等形式向社区通报最新成果。
其中会展示关键指标，如合并的拉取请求数量、新增贡献者人数以及通过的网络平台测试（Web Platform Tests, WPT）数量，这些都证明了项目的健康发展态势。
兼容性#
在衡量浏览器引擎标准兼容性的权威基准，WPT 测试套件中，Ladybird 取得了令人瞩目的进展。截至 2025 年 3 月，其测试通过率排名第四，仅次于 Chrome、Safari 和 Firefox 这三大成熟的浏览器引擎。对于一个从零开始的新引擎而言，这是一个非凡的成就。
JS 性能#
Ladybird 自研的 JavaScript 引擎 LibJS 在标准符合性方面表现同样出色。WPT 的测试结果显示，LibJS 是仅次于 Firefox 的 SpiderMonkey 引擎的第二大符合规范的 JavaScript 引擎。
架构#
Ladybird 的技术核心是其完全自研的引擎组件：LibWeb 和 LibJS。
LibWeb 负责处理 HTML 解析、DOM 构建、CSS 渲染等所有与网页内容呈现相关的任务。
而 LibJS 则是一个完整的 ECMAScript 引擎，负责执行网页中的 JavaScript 代码。
项目最初完全使用 C++ 语言编写，这主要是继承自其在 SerenityOS 项目中的技术选型。
独立之后，团队正在积极评估并计划引入一种内存安全的语言（如 Swift）作为项目的第二开发语言，以期在未来提升代码的安全性和健壮性。
此外，在代码量上，Ladybird 的 C++ 代码约为 42.5 万行，而 Chromium 项目的代码量则高达约 3200 万行以上。（虽然少了几个平台吧，但是整体来说确实很精简了）
这种精简的架构带来了多重优势。
首先，它显著降低了维护成本和复杂性。
其次，更小的代码库使得新贡献者更容易理解整个系统的运作方式，从而降低了参与门槛。
最后，这种可破解性（hackable）的特质鼓励了实验和创新，为快速迭代和实现新功能创造了有利条件。
像 Blink 和 Gecko 这样的浏览器引擎，是经过数十年开发、积累了数百万行代码的庞大系统 ，它们不可避免地携带了支持旧标准和适应架构演进所产生的历史复杂性。
相比之下，Ladybird 诞生于 2020 年代，能够从一开始就基于现代软件工程原则（如多进程隔离、内存安全）进行全新设计，无需对庞大而根深蒂固的旧代码进行重构。
其显著更小的代码库，更易于单个开发者全面理解，这降低了项目对少数核心开发者的依赖，并有助于做出更具整体性的架构决策。
这意味着，在实现新的网络标准或进行架构调整时，Ladybird 可能比那些受制于庞大遗留系统惯性的老牌引擎更加迅速。
多线程#
Ladybird 采用了现代化的多进程架构，这是其安全设计的核心。该架构将主用户界面进程与多个沙盒化的 WebContent 渲染进程严格隔离，每个浏览器标签页都运行在自己独立的渲染进程中。
此外，图像解码和网络请求等敏感操作也被置于独立的进程中处理。
这种设计被认为是关键的安全优势。通过将不同功能的模块分散到隔离的进程中，即使某个渲染进程因处理恶意网页内容而崩溃或被攻破，其影响也会被限制在该进程的沙盒内，从而保护主 UI 进程和整个操作系统的安全，极大地减小了攻击面。
挑战#
要成为一个可行的主流浏览器替代品，Ladybird 面临的首要技术挑战是实现与现代浏览器的功能对等。
这是一个艰巨的任务，因为它不仅意味着要实现数量庞大且不断扩展的 Web API，还需要在各种各样的网站上实现像素级的精确渲染，并支持浏览器扩展、高级媒体编解码器等复杂功能。
项目目前仍处于让它能用（make it work）的阶段，未来必须过渡到让它好用（make it good）和让它快（make it fast）的阶段。
这意味着需要对渲染管线和 JavaScript 执行进行深度优化，这是一个资源密集型且需要持续投入的长期过程。
在安全方面，除了已有的架构级沙盒隔离，还需要进行持续的安全加固。现代浏览器的安全维护成本极高，谷歌等公司每年在漏洞赏金计划（Bug Bounty）上投入数百万美元，而在 Pwn2Own 等顶级黑客大赛上，针对主流浏览器的零日漏洞利用更是屡见不鲜。
Ladybird 要想获得用户信任，就必须建立起同样强大的安全响应和防御体系。
Ladybird 最大的非技术性障碍，不仅仅是构建浏览器本身，而是要克服网络生态中自我强化的 Chromium 反馈循环。
由于 Chromium 在市场上的主导地位，绝大多数 Web 开发者会优先在 Chrome 中测试他们的网站 。这导致了一个事实上为 Blink 引擎的特定实现（包括其存在的 bug 和非标准行为）而优化的网络。
当像 Ladybird 这样的新浏览器正确地实现了某个标准时，它在访问那些依赖于 Chromium 特定怪癖的网站时，反而可能会出现渲染错误。
尽管 Ladybird 的行为更符合规范，但在用户看来，网站却 bug 了。
这种现象会给用户和开发者造成新浏览器充满 bug 的印象，从而进一步巩固了他们对 Chromium 的偏好。
因此，Ladybird 不仅要做到标准兼容，还可能需要花费大量工程资源去实现对这个以 Chromium 为中心的网络的兼容性。
勇士#
勇者斗恶龙的故事我们听过不少。Ladybird 的出现，就像是这个被 Chromium 巨龙阴影笼罩的王国里，一位敢于拔剑的勇士。我们为它的勇气喝彩，也为它渺茫的胜算担忧。
我们总会下意识地问：这位勇士最终会变成新的恶龙吗？
但这或许从一开始就问错了问题。
谷歌与美国司法部的博弈，以及未来可能出现的 Chrome 新主人，本质上都是在讨论由谁来坐上铁王座。
反垄断的利剑挥下，或许能砍倒一位国王，但只要王座还在，就总会有下一个觊觎者。
将 Chrome 从一家巨头手中交给另一家，很可能只是将皇冠从一个国王，交给了另一个国王，却丝毫没有改变我们都活在国王掌控之下的事实。
这正是 Ladybird 带来的、超越勇士斗恶龙的真正意义。
它不是为了成为新的国王，而是作为一名信使，带来一个振聋发聩的消息。
世界本不必有国王。
Ladybird 的价值，不在于它能否在短期内取代 Chrome，而在于它的存在本身，就是对当前网络世界唯一最优解的有力证伪。
它以每一行从零写下的代码证明，通往未来的道路不止一条。它可以是一条回归开放、由社区共建、将用户而非数据放在首位的道路。
这让我们每个人的每一次选择，都变得前所未有的重要。
当我们选择浏览器时，我们选择的不仅仅是一个工具，更是在为我们想要的未来投票。
是选择一个由高效、仁慈但唯一的君主统治的中央帝国，还是选择一个充满多样性、或许有些混乱（真的很混乱吗？比如 Mastodon vs X）但充满韧性和自由的城邦联盟？
反垄断的最终目的，或许不应是扶持更多的公司去争夺王座，而是要确保我们永远拥有创造一个没有王座的世界的权利和可能。
而像 Ladybird 这样的项目，正是守护这份可能性的星星之火。