前言如果你打开设置看一下自己正在用的浏览器大概率会发现一个事实Chrome、Edge、Opera、Brave、Vivaldi、Arc、甚至国产的大多数浏览器底层都是同一个引擎家族——Chromium。在整个桌面浏览器市场非 Chromium 的选择几乎只剩 SafariWebKit和 FirefoxGecko。但 2026 年有一个项目正在做一件「不太聪明」的事完全不基于 Chromium从零开始写一个浏览器引擎。它叫Ladybird由 GitHub 联合创始人 Chris Wanstrath 主导目标是在 2026 年夏天发布 alpha 版本仅支持 Linux 和 macOS。这件事听起来很浪漫——「打破 Chromium 垄断」「重塑 Web」。但如果你写过任何系统级软件第一反应大概是为什么为什么要在 2026 年去重做一件 Google 投入了上万名工程师、干了快二十年、代码已经堆到几千万行的事这篇文章不聊 AI回到浏览器引擎本身拆解「从零写一个浏览器引擎」到底难在哪。我们会讲清楚现代浏览器引擎的复杂度来源、渲染管线的五个核心阶段、JavaScript JIT 引擎为什么会吞噬一切工程量以及 Ladybird 选择 LibWeb LibJS 路线的工程意义。本文面向对浏览器引擎、编译原理、C 系统编程感兴趣的开发者。文中的代码规模、架构描述基于公开资料具体数字会随版本变化重点在于理解复杂度量级。背景或问题Chromium 一统天下之后先把现状摆清楚。浏览器渲染引擎JS 引擎是否基于 ChromiumChromeBlinkV8— (本身就是 Chromium)Edge / Opera / Brave / Vivaldi / ArcBlinkV8是SafariWebKitJavaScriptCore否自家FirefoxGeckoSpiderMonkey否自家LadybirdLibWeb自研LibJS自研否从零这张表揭示了一个尴尬的事实所谓「浏览器市场竞争」在引擎层面其实早就没什么竞争了。绝大多数浏览器只是给 Chromium 套了不同的壳和功能真正的引擎差异只在 Apple 和 Mozilla 手里。而这两家维护 WebKit 和 Gecko 的成本同样惊人——都是几十年积累、上千人规模的工程。在这样的格局下从零写一个新引擎意味着你要独自扛起 Google、Apple、Mozilla 三家加起来才扛得动的复杂度。Ladybird 为什么还要做要回答这个问题得先看清楚这个复杂度到底是什么。核心思路现代浏览器引擎到底有多复杂很多人对浏览器复杂度的直觉是「不就是渲染网页嘛」。但「渲染网页」这四个字背后藏着一个相当于一整套操作系统平台的工作量。复杂度来源一三套规范丛林一个现代浏览器要正确渲染页面至少要实现三套庞大且各自独立的规范HTML 规范定义文档结构、解析规则、各种元素行为单单一个 parsing 算法就足以写满几十页。CSS 规范不是一份文档而是几十份独立模块的集合CSS Selectors、Flexbox、Grid、Animations、Transforms、Variables……CSS Working Group 持续在加新模块。JavaScript 规范ECMAScript每年更新一版加上 TypeScript 已成事实标准、各种 polyfill、新语法糖。这只是三大主干还没算上DOM、WebGL/WebGPU、WebRTC、WebAssembly、Service Worker、IndexedDB、Web Components等几十个独立 Web 平台 API。每一个 API 背后都是一份甚至多份 W3C/WHATWG 规范加上数不清的 RFC。一个常被引用的体感数字现代浏览器的规范文档总量换算成代码行数的话已经是「千万行级」的工程规模。这意味着一个新引擎想「追平」现有浏览器不是写一年两年的事而是要持续投入一个大型团队干很多年。复杂度来源二渲染管线的五个阶段无论用哪个引擎把一份 HTML 渲染成屏幕上的像素都要走一条相当长的流水线。这是理解「为什么浏览器引擎难写」最关键的一节。阶段 1HTML 解析Parsing浏览器拿到字节流按 HTML 规范的解析算法构建出一棵DOM 树。这一步要处理错误的、不规范的、历史上为了「容错」而遗留的各种奇怪写法——浏览器对错误 HTML 的容错能力本身就是规范的一部分这部分容错逻辑极其繁琐。阶段 2样式计算Style对 DOM 树里每个节点计算它最终应用的样式值。CSS 的层叠cascade、继承、优先级规则要在这里全部正确实现。一个元素可能命中几十条选择器浏览器要算出最终生效的每一条属性。CSS 还包含大量隐式规则比如display的某些值会触发别的属性变化错一处整个布局就崩。阶段 3布局Layout / Reflow有了带样式的 DOM 树下一步是算出每个元素的几何位置——宽度、高度、x、y。Flexbox、Grid、浮动、定位、文字换行、margin 折叠……每一项都是一个独立的算法难题。布局通常是递归的父元素尺寸依赖子元素子元素又反过来影响父元素需要多轮迭代才能收敛。阶段 4绘制Paint算好位置后把每个元素画成一组「绘图指令」——文字怎么渲染、边框怎么画、阴影怎么合成。这一步要处理字体光栅化、抗锯齿、渐变、透明度叠加任何一个细节做错肉眼立刻能看出违和。阶段 5合成Composite现代浏览器为了性能会把页面拆成多个「图层」分别绘制后由 GPU 合成。这引入了一个完整的 GPU 编程子系统——着色器、纹理管理、合成层触发条件。这也是为什么浏览器在 GPU 适配上的 bug 层出不穷。这五个阶段任何一个出了偏差页面就「看起来不对」——而对 Web 来说「看起来不对」就等于「不能用」。更麻烦的是这五步还要和 JavaScript 互锁JS 可以随时改 DOM触发样式重算和重新布局浏览器必须精确管理这种「一边渲染一边被脚本改」的并发关系。复杂度来源三JavaScript 引擎是「工程黑洞」如果上面四个渲染阶段还不够劝退那么 JavaScript 引擎才是真正的「工程黑洞」。一个现代 JS 引擎要做的事远不止「解释执行」解析与字节码生成把源码解析成 AST再编译成中间字节码V8 的 Ignition、SpiderMonkey 的 Baseline。JIT 编译对热点代码用优化编译器生成机器码V8 的 TurboFan、SpiderMonkey 的 Warp。这一步涉及类型推断、内联缓存、去优化机制——任何一个搞错要么性能崩要么正确性出错。垃圾回收GCJS 是托管内存语言引擎要实现分代 GC、并发标记、对象移动。一个高质量的 GC 子系统本身就是一篇博士论文的体量。WebAssembly现代 JS 引擎还要跑 WASM等于在同一个引擎里再塞一个完全不同的编译目标。一个直观的对比V8 和 SpiderMonkey 各自都是千万行级的项目单独拎出来都是世界级的编译器工程。一个新浏览器引擎如果自己写 JS 引擎等于在写渲染引擎的同时又写了一个 V8。这也就是为什么绝大多数浏览器选择直接复用 V8——不是不想差异化而是自己重写一个 JS 引擎的成本高到不现实。Ladybird 选择自研 LibJS是这个项目工程野心最直接的体现。实现步骤Ladybird 怎么走这条路讲清楚复杂度之后再看 Ladybird 的具体技术路线就能理解它的每一个选择都在和上述复杂度作斗争。路线一自研 LibWeb LibJS不依赖任何现有引擎这是 Ladybird 最根本的决定渲染引擎LibWeb和 JS 引擎LibJS都自己写不 fork Chromium、不套 WebKit、不嵌 V8。这个选择的代价是巨大的——它意味着 Ladybird 要独自实现上面说的全部规范、全部渲染阶段、全部 JS 引擎能力从零追赶到现有浏览器的兼容度。但收益也很明确它不继承任何历史包袱。Chromium 和 WebKit 里大量的代码是在为二十年前的 Web 兼容性服务新引擎可以从一开始就只支持现代 Web扔掉一大堆遗留兼容逻辑。路线二单进程架构起步强调可读性和可维护性Ladybird 在早期采用相对简单的单进程或多进程轻量化架构而不是 Chromium 那种复杂的多进程 sandbox 模型。这不是因为单进程更先进而是先把引擎写对再谈优化和安全隔离。Chromium 的多进程架构是为了生产环境的稳定性和安全性服务的但代价是工程复杂度极高。Ladybird 选择先聚焦「正确性」把规范实现做扎实。这条路线对学习浏览器引擎的人特别友好LibWeb 和 LibJS 的代码量比 V8/Blink 小一两个数量级更容易读懂一个完整的浏览器引擎是怎么运转的。路线三从独立项目孵化Ladybird 起源于 SerenityOS 项目一个自研操作系统原本是它的浏览器组件后来独立出来作为通用浏览器开发。这种从「教学/研究型项目」成长起来的路径决定了它目前更像是「一个开放的浏览器引擎实验场」而不是「要立刻抢 Chrome 份额的产品」。需要诚实地说Ladybird 短期内对市场格局几乎没有影响。它的 alpha 版本只支持 Linux 和 macOS目标是「能正确渲染现代网页」而不是「立刻成为你的日常浏览器」。它的真正价值在于工程层面——它是目前唯一一个完全不基于 Chromium/WebKit/Gecko 的开源浏览器引擎尝试。常见问题与避坑Q1为什么 Brave、Edge 这些浏览器都 fork Chromium而不是自己写引擎因为成本。Chromium 已经把规范实现、JIT、GC、多进程架构、GPU 适配都做完了fork 它只要做上层差异化隐私、广告拦截、UI就能快速上线。自己写引擎意味着把过去二十年 Google/Apple/Mozilla 的活儿重干一遍商业上不划算。这是「商业理性」和「工程野心」的分野。Q2既然 WebKit 和 Gecko 也是非 Chromium 引擎为什么 Ladybird 还要再做因为 WebKit 和 Gecko 同样是几十年的老项目背负了大量历史兼容代码而且本质上还是由 Apple 和 Mozilla 两家公司主导。Ladybird 想要的是一个「没有公司单方面掌控、从现代 Web 起步、代码可读」的新选择这个生态位目前是空的。Q3写一个「能跑的」浏览器 Demo 难吗写一个能渲染简单 HTML 的 Demo 不难——几百行 C 或 Python 加一个 GUI 框架就能起步推荐看「浏览器引擎」系列教程比如browser.engineering。但「能跑」和「能正确渲染现代网页」之间隔着一个数量级的复杂度——现代网页的 CSS、JS、动态布局会把任何简化实现瞬间打回原形。Q4Ladybird 会支持 Windows 吗alpha 阶段只支持 Linux 和 macOS。Windows 支持在路线图上但不是首要目标。这反映了项目资源有限的现实——先把核心引擎做扎实再扩展平台。Q5AI 时代还需要关心浏览器引擎吗需要而且更重要了。当 AI Agent 开始在浏览器里替用户操作网页参见上一篇 Agent 浏览器权限模型引擎的稳定性、安全隔离、对 DOM 的可控性直接决定了 AI 自动化能走多远。一个被 Chromium 垄断的引擎生态长期看对 Web 平台的开放性是风险——Ladybird 这类独立引擎的存在本身就是在为这种风险兜底。总结从零写一个浏览器引擎之所以难不是因为某一处特别复杂而是因为它的复杂度是「全栈」的HTML/CSS/JS 三套规范丛林、渲染管线五个互相耦合的阶段、JIT 与 GC 构成的 JS 引擎黑洞、再加上 WebAssembly/WebGPU 等不断扩张的平台 API。任何一个环节的偷懒都会让整个引擎「渲染出来不对」。Chromium 一统天下是工程理性下的结果——重写这一切太贵了。但 Ladybird 的存在提醒我们当一个平台只剩一个实现这个平台就不再是真正开放的。即便 Ladybird 永远不会取代 Chrome它作为一个不继承任何历史包袱的独立引擎实验本身就值得被看见。它给 Web 平台保留了一种「如果有一天 Chromium 走向封闭我们还有 Plan B」的可能性。写到这里回头看这周关于浏览器的三篇文章恰好是从产品到工程到引擎的一条线索先是 AI 代理浏览器在产品层重塑「浏览器是什么」再是 Agent 浏览器在工程层必须重新设计权限模型最后是浏览器引擎本身在更底层决定着这一切能跑在什么样的地基上。浏览器的故事远没有到结局。