浏览器引擎这个词，大部分前端同学可能只在面试八股里见过，真正动手碰过的人不多。但只要你做过自动化测试、爬虫渲染、桌面端内嵌网页、跨端应用，或者被某个“只有某个浏览器上才复现”的诡异 Bug 折磨过，你就一定会绕回到这个问题上：市面上这些浏览器引擎，到底差在哪，我该选哪个。我这些年从做爬虫时被渲染结果坑，到做桌面客户端时纠结内嵌方案，再到带团队做多内核兼容测试，来来回回踩了不少坑。这篇就把我理解的浏览器引擎从架构分层、各家家底、代码层面的差异，一直到怎么自己搭一套横向测试环境，完整捋一遍。不管你是刚入行的前端，还是做客户端、做测试、做数据采集的老手，应该都能从中拿到可以直接用的东西。
1. 先把概念掰开：浏览器引擎到底分几层
1.1 渲染引擎、JS 引擎、网络栈不是一回事
很多人嘴里说的“浏览器引擎”其实是个混合概念。严格拆开，一个浏览器至少包含四块相对独立的东西：渲染引擎负责把 HTML 解析成 DOM 树、把 CSS 解析成规则树、做布局计算、绘制、合成上屏；JS 引擎负责执行脚本，管着解析、字节码、JIT 编译和垃圾回收；网络栈处理连接复用、缓存、协议协商；图形后端负责最终把绘制指令变成 GPU 能吃的纹理。日常说的“哪家引擎强”，八成指的是渲染引擎，但实际上你遇到的性能问题，很多时候锅在 JS 引擎或者合成器上。
这个区分很重要，因为它直接决定了你优化时的下手位置。举个我自己的例子：早年做一个长列表页面，滚动卡得厉害，我一开始以为是 JS 引擎不够快，把数据处理逻辑重写了一版，结果毫无改善。后来用性能面板一看，主线程的脚本时间只占 8%，剩下全是布局和绘制。真正的问题是每一行都触发了布局抖动，改成一个合成层加transform位移之后立刻就顺了。引擎的强弱不是单维度的，渲染管线设计和 JS 执行效率是两条平行的赛道，你得先搞清楚自己卡在哪条赛道上。
还有一层经常被忽略的，就是绑定层。JS 引擎和渲染引擎是两套 C++ 代码，DOM 就是它们之间的桥。你写一句document.getElementById('a').style.width = '100px'，背后要经历类型转换、跨模块调用、属性校验、样式失效标记、重新布局调度。这层桥的成本，往往比 JS 执行本身还要高。所以你会看到一个反直觉的现象：同样一段逻辑，用不同的写法，在同一个引擎上性能能差出三四倍，而在不同引擎之间的差距反而没那么大。
1.2 一个请求从输入到画面的完整链路
想理解引擎差异，最好的办法是把一次页面加载完整走一遍。用户在地址栏敲下地址，浏览器进程先做 URL 解析和安全检查，然后交给网络进程发起请求；响应回来后，渲染进程拿到字节流，先是 HTML 解析器边下边解析，边构建 DOM；遇到 CSS 就并行拉取并解析成样式规则；遇到脚本，如果没加异步属性，就会阻塞解析去执行。DOM 和样式都准备好之后，进入布局阶段，算出每个盒子的位置和尺寸；然后是绘制，把盒子变成绘制指令；最后是合成，把分层的绘制结果合成为一帧交给 GPU 上屏。
这条链路上每一环，各家引擎的设计取舍都不一样。有的引擎把解析器和网络层耦合得很紧，追求首字节到首屏的极限速度；有的引擎在合成阶段做得更激进，愿意多分几层换取滚动流畅；有的引擎在内存上抠得很死，宁可牺牲一点渲染质量。这些取舍在普通页面上你感知不到，但一旦到了低端设备、复杂动画、超大文档这些极端场景，差异就会被放大到无法忽视。
多进程架构也是一个关键分水岭。渲染进程独立、站点隔离、沙箱化，这些机制决定了单个页面崩溃时会不会拖垮整个应用，也决定了内存的基线开销。我用过的一个内嵌方案，单实例内存占用接近 200MB，其中相当一部分是进程模型带来的固定成本。如果你的场景是几十个实例并存的批处理，这个固定成本会直接把你的机器压垮，这时候就得考虑单进程模式或者更轻量的嵌入式方案，而不是一味追求“最新最强的引擎”。
2. 主流引擎横向盘点：各自的家底与适用场景
2.1 Blink 系：生态最厚，代价是体积和内存
Blink 是从 WebKit 分叉出来的，现在是市面上占有率最高的渲染引擎，绝大多数桌面和移动端浏览器都基于它。它的最大优势不是某一项技术指标领先，而是生态厚度：新特性最先落地、开发者工具的调试体验最完善、自动化测试工具链支持最好、各种边界情况的兼容性问题被踩得最透。你在别的引擎上遇到的坑，在 Blink 上大概率已经有人踩过并且有现成答案。
代价也很明确。一是体积，完整的 Blink 加 JS 引擎编译出来，二进制尺寸是百兆级别的，对于需要瘦身的客户端来说很难接受；二是内存基线，多进程模型加上各种缓存，空页面就能吃掉不少内存；三是版本迭代快，新特性上线和老特性废弃都很激进，如果你的产品需要长期维护，会不断面临“昨天还好好的今天就不兼容了”的情况。
我个人的判断是：面向公网的 Web 产品，Blink 是默认答案，没有之一，因为你的用户大概率就在用它，兼容性风险最低。但如果是内嵌场景、离线场景、需要长期冻结版本的场景，就得认真评估体积和内存成本了，不要因为“主流”两个字就无脑选。
2.2 WebKit 系：端侧优化的老玩家，系统集成度最高
WebKit 的历史比 Blink 更久，它在移动端和系统级集成上的积累非常深。很多移动操作系统的浏览器组件、应用内网页视图，底层都是它。它的特点是在功耗和内存上做得比较克制，渲染管线和系统图形栈的结合也更紧密，所以在续航敏感的设备上往往表现更好。
从开发者视角看，WebKit 的一个特点是对新标准的采纳节奏相对保守。这不是坏事，保守意味着它更在意既有页面的稳定性，但对想用最新 CSS 特性的前端来说就比较难受了，经常需要写降级方案。另一个特点是它的调试工具和自动化接口跟 Blink 系不完全一致，如果你只熟悉一套工具链，换过去会有一段适应期。
我在做跨端项目时感受最深的一点是：同一个页面在 WebKit 上的字体渲染和滚动惯性跟 Blink 有明显差异。这不是 Bug，是渲染策略和系统集成方式不同导致的。如果你的设计稿对像素级对齐要求很高，或者有依赖滚动位置的计算逻辑，一定要在两端都实测，不要靠模拟器猜。
2.3 Gecko 系：独立实现的坚持，标准推进的急先锋
Gecko 是三大主流引擎里唯一一个独立实现、没有从别人那里分叉出来的。这个“独立”很有价值：它意味着标准组织在推进新规范时，有一个真正独立的实现来验证规范本身是否可实现、是否有歧义。很多规范里含糊的地方，就是被独立实现逼着写清楚的。
从工程角度看，Gecko 这些年最大的变化是引入了并行化架构，把样式计算、布局这些原本串行的环节拆到多个线程上跑，大幅降低了主线程压力。这个设计思路和 Blink 的合成器优先策略不太一样，它更倾向于从源头并行化，而不是靠分层来绕开主线程。实际体感上，在复杂 CSS 的场景里，Gecko 的表现往往比较稳。
对普通开发者来说，Gecko 的现实意义主要有两个：一是兼容性验证，如果你的页面在 Gecko 上跑不通，大概率是用到了非标准的东西或者依赖了某个引擎的实现细节，这是个很好的自查手段；二是自动化测试的第二内核，用两套独立实现跑同一套用例，能捞出大量隐藏的兼容性问题。我现在做重要项目，测试矩阵里一定会包含 Gecko，哪怕用户占比不高。
2.4 已退役与新生代：历史教训和未来变量
说完三家主流，得说说那些退场的和正在路上的。曾经有一个引擎靠系统捆绑占据了大量份额，但长期不跟进标准，最后在移动浪潮里被彻底边缘化；还有一个引擎是某系统为了摆脱依赖自己做的，技术上不算差，但生态没跟上，最终也转向了别人的内核。这两个案例的教训是一致的：引擎的竞争从来不是纯技术竞争，生态和标准跟进速度才是生死线。一个引擎哪怕渲染得再快，只要新特性上不去、开发者不愿意适配，就注定会被淘汰。
新生代这边，值得关注的有两个方向。一个是主打内存安全和并行化的新引擎，用现代系统级语言从零写起，把布局和样式计算做成真正的并行流水线，思路很激进，但目前更多是实验性质，生产可用性还差得远。另一个是完全从零实现的独立引擎，不依赖任何现有代码库，自己写解析器、自己写布局、自己写 JS 引擎，野心很大，理念也很纯粹，但同样处在早期阶段，能跑通的网站范围有限。
我把这几个引擎的关键差异整理成了下面这张表，方便快速对照：
| 引擎 | 出身 | 许可风格 | 主战场 | 突出优势 | 明显短板 |
|---|---|---|---|---|---|
| Blink | 从 WebKit 分叉 | 宽松开源许可 | 桌面与移动端主流浏览器 | 生态最全、特性最新、工具链最好 | 体积大、内存基线高、迭代激进 |
| WebKit | 独立演进多年 | 宽松开源许可 | 移动端、系统内嵌视图 | 功耗与内存克制、系统集成深 | 新特性采纳偏保守、工具链差异 |
| Gecko | 完全独立实现 | 开源许可 | 独立浏览器 | 标准验证价值高、并行化架构彻底 | 市场份额小、部分新特性滞后 |
| Servo | 现代语言重写 | 开源许可 | 实验与研究 | 内存安全、并行布局 | 生产可用性不足 |
| Ladybird | 从零自研 | 开源许可 | 独立浏览器探索 | 完全不依赖现有实现 | 早期阶段、站点覆盖有限 |
| Trident | 系统捆绑时代产物 | 闭源 | 已退役 | 曾经的兼容性包袱 | 标准停滞、生态流失 |
| EdgeHTML | 自研尝试 | 闭源 | 已退役 | 一度性能不错 | 生态没跟上、最终转投 |
3. 从代码视角看差异：解析、布局、合成、绑定
3.1 布局与合成：掉帧到底掉在哪
要理解引擎差异，绕不开布局和合成这两个阶段。布局是把样式树变成几何信息，算出每个盒子在哪儿、多大；合成是把绘制结果按层合并成最终画面。现代引擎普遍采用分层合成策略：把页面拆成多个图层，滚动和变换类动画只需要移动图层，不需要重新布局和重绘，直接在合成线程上完成。这就是为什么transform和opacity的动画比left和width流畅得多。
但分层是有成本的。每一层都要占一块显存，层数多了内存会飙升，合成本身的开销也会增加。我在一个数据可视化项目里踩过这个坑：为了让每个图表块都有独立动画，给几十个元素都加了will-change: transform，结果在低配机器上内存直接翻倍，页面反而更卡。后来改成只给真正在动的少数元素分层，其余走普通绘制，问题才解决。分层不是越多越好，它是一笔显存换流畅度的交易，得算账。
不同引擎在分层策略上的默认行为不一样。有的引擎倾向于激进分层，动画流畅但内存吃得多；有的引擎更保守，内存省但复杂动画容易掉帧。这个差异在桌面端你可能感知不到，但在中低端移动设备上非常明显。所以做性能优化时，不要只在自己开发机上测，一定要找一台配置接近用户真实设备的机器跑一遍，最好再借用引擎的图层可视化工具看看实际分了多少层。
3.2 JS 引擎与 DOM 绑定：真正的大头在桥接层
很多人以为 JS 性能就是引擎跑得快不快，其实在真实页面里，纯计算的时间占比往往不高，大头在JS 和 DOM 之间的来回调用。每一次读写 DOM 属性，都要跨过一次语言边界，涉及类型转换、属性查找、样式失效标记。如果在一个循环里反复读写布局相关属性，就会触发所谓的布局抖动——读一次强制同步布局，写一次让布局失效，下一次读又强制布局，循环往复，性能呈指数级恶化。
我见过最典型的一段烂代码是这样的：循环里先设置元素宽度，再读取它的偏移宽度做判断。看着没问题，实际上每次循环都强制了一次完整布局。改成先批量读、再批量写，中间不做交叉，耗时从 800 毫秒降到了 30 毫秒。这个优化跟用哪个引擎无关，是所有引擎通用的规则，但不同引擎对布局抖动的惩罚力度不同，有的引擎有缓存机制能稍微兜一下，有的就直接硬算。
绑定层的另一个差异点是对象模型和垃圾回收。不同 JS 引擎对对象形状的优化策略不同，有的对动态添加属性很宽容，有的则要求你尽量保持对象结构稳定。我在做大数据量渲染时发现，同样的对象构造方式，在一个引擎上能保持在几十毫秒，在另一个引擎上会因为频繁的结构变化触发优化退化，慢上好几倍。解决办法是提前把对象结构定死，用工厂函数统一创建，不要到处动态挂属性。
3.3 特性支持差异怎么量化，别靠 UA 猜
判断引擎能力，最不靠谱的办法就是读 User-Agent 字符串。UA 可以被随意改写，而且现在的 UA 冻结策略让版本号越来越没有参考价值。正确做法是特性检测：CSS 用@supports或CSS.supports()，JS 用typeof或者尝试构造，API 用能力探测。这样不管底层是什么引擎，只要它支持这个特性，代码就能跑。
// CSS 特性检测 if (CSS.supports('display', 'grid')) { // 走网格布局 } // JS API 能力探测 const hasResizeObserver = typeof ResizeObserver !== 'undefined'; // 更细粒度的行为检测，而不是版本检测 const supportsSmoothScroll = 'scrollBehavior' in document.documentElement.style;如果要量化比较不同引擎对标准的实现程度，最权威的参考是Web 平台测试套件的一致率。这套测试是各家共同维护的，覆盖了 DOM、CSS、网络、安全等几乎所有规范条目，通过率能比较客观地反映实现完整度。我一般会关注几个关键领域的通过率，而不是只看总分，因为总分会被大量边缘用例稀释，真正影响你的是你用到的那部分。
除了标准测试，还得看实际项目里的行为差异。有些特性各家都“支持”，但边界行为不一样，比如日期字符串解析、数字格式化、滚动条占位宽度、表单控件的默认样式。这些东西规范里写得不够细，各家就按自己的理解实现，结果就是你写的时候好好的，换个引擎就错位了。我的经验是：凡是涉及本地化格式、滚动容器尺寸、表单原生控件的，一律做兜底处理，不要假设行为一致。
4. 实操：自己动手搭一套引擎横向测试
4.1 测试环境与用例设计
光看文档吹没用，自己跑一遍数据才靠谱。我的做法是用支持多内核的自动化工具搭一套最小测试台，把同一批页面在三个主流内核上各跑一遍，采集关键指标做对比。工具选型上，我倾向用那套能同时驱动三种内核的自动化框架，它的接口统一，切换内核只需要改一个参数，省去了维护三套脚本的麻烦。
用例设计上不要贪多，抓住四类就够：首屏性能（首字节、首次绘制、最大内容绘制）、交互响应（长任务数量、输入延迟）、渲染正确性（关键元素的位置尺寸、字体度量、滚动条宽度）、资源占用（JS 堆大小、DOM 节点数、图层数量）。每类挑两三个有代表性的页面，比如一个图文长列表、一个动画密集型页面、一个表单密集页面、一个超大表格页面。
环境控制是容易被忽略的一环。同一台机器、同一网络条件、同样的视口尺寸、禁用缓存和扩展、每个用例跑三次取中位数。我一开始没做这些控制，跑出来的数据抖得厉害，同一内核两次结果能差 30%，根本没法比较。加上预热和多次采样之后，数据才稳定下来。
4.2 用自动化脚本跑多内核对比
下面这段是我常用的采集骨架，逻辑很简单：起三个内核，逐个打开目标页面，等加载完成，抓性能条目和布局指标，输出成结构化数据。
from playwright.sync_api import sync_playwright import json, statistics TARGETS = [ {"name": "long-list", "url": "http://localhost:8080/list.html"}, {"name": "animation", "url": "http://localhost:8080/anim.html"}, {"name": "form-heavy", "url": "http://localhost:8080/form.html"}, ] ENGINES = ["chromium", "firefox", "webkit"] ROUNDS = 3 def collect(page): page.wait_for_load_state("networkidle") page.wait_for_timeout(1500) # 给动画和懒加载留时间 return page.evaluate("""() => { const nav = performance.getEntriesByType('navigation')[0] || {}; const paints = {}; performance.getEntriesByType('paint').forEach(p => paints[p.name] = p.startTime); const lcp = performance.getEntriesByType('largest-contentful-paint').pop(); return { domContentLoaded: nav.domContentLoadedEventEnd, loadEvent: nav.loadEventEnd, firstPaint: paints['first-paint'] || null, firstContentfulPaint: paints['first-contentful-paint'] || null, largestContentfulPaint: lcp ? lcp.startTime : null, domNodes: document.getElementsByTagName('*').length, jsHeap: performance.memory ? performance.memory.usedJSHeapSize : null, scrollbarWidth: window.innerWidth - document.documentElement.clientWidth, bodyHeight: document.body.getBoundingClientRect().height }; }""") results = {} with sync_playwright() as p: for engine in ENGINES: browser = getattr(p, engine).launch(headless=True) ctx = browser.new_context(viewport={"width": 1366, "height": 768}) page = ctx.new_page() for t in TARGETS: samples = [] for _ in range(ROUNDS): page.goto(t["url"], wait_until="load") samples.append(collect(page)) # 取中位数，抵抗抖动 merged = {} for k in samples[0]: vals = [s[k] for s in samples if s.get(k) is not None] merged[k] = statistics.median(vals) if vals else None results.setdefault(engine, {})[t["name"]] = merged browser.close() print(json.dumps(results, indent=2, ensure_ascii=False))跑完之后你会得到一份类似下面的对比数据（我这里填的是示意值，你实际跑出来的绝对数值会不一样，重点看相对差距）：
| 指标 | Blink 系 | Gecko 系 | WebKit 系 |
|---|---|---|---|
| 首次内容绘制 | 420ms | 455ms | 438ms |
| 最大内容绘制 | 1180ms | 1260ms | 1210ms |
| 长任务总时长 | 340ms | 290ms | 310ms |
| JS 堆占用 | 18.6MB | 15.2MB | 16.4MB |
| 滚动条宽度 | 15px | 12px | 0px（覆盖式） |
| 长列表滚动帧率 | 58fps | 56fps | 59fps |
这张表最有价值的不是谁快谁慢，而是最后两行。滚动条宽度不一致会直接导致你的布局计算错位，覆盖式滚动条意味着容器宽度比你以为的多出 15 像素；帧率的小幅差异在桌面端无感，但在低端设备上会被放大成肉眼可见的卡顿。这类差异没法靠读文档知道，只能实测。
4.3 数据怎么读，别被平均数骗了
拿到数据之后，最容易犯的错是只看平均值。我第一次做这类对比时，看到最大内容绘制只差 60 毫秒，觉得差不多，结果用户投诉说某个页面上特别慢。回头一看分布，那个页面在一个内核上有 10% 的样本超过 3 秒，平均值被大量的快样本拉平了。一定要看分位数，尤其是 75 分位和 95 分位，那才是真实用户感受到的体验。
第二个容易犯的错是忽略测试机和使用设备的差距。开发机是高性能配置，跑什么都是 60 帧，但用户手里的设备可能是几年前的中端机，CPU 核心数少、内存小、GPU 弱。我的做法是把测试机的 CPU 降频模拟，或者直接在低配设备上跑一轮，往往能暴露出在高性能机器上完全看不到的问题。
第三个是指标之间的因果关联。比如你发现某个内核的 JS 堆占用高，别急着下结论说它内存管理差，很可能是它的缓存策略更激进，换来了更快的二次访问。这时候应该结合首屏时间和重复访问时间来一起看，判断这个内存换速度的交易值不值。单看一个指标，很容易得出错误结论。
4.4 内嵌场景的选型：三种方案的真实取舍
前面说的都是公网 Web，但实际工作中，浏览器引擎更多是作为内嵌组件出现的：桌面客户端里嵌网页、工业软件里嵌界面、数据采集工具里跑无头渲染。这块的选型逻辑跟公网 Web 完全不同，我把它分成三类。
第一类是完整内嵌方案，把整个引擎连同外壳一起编译进你的程序，好处是版本完全由你控制、接口丰富、渲染行为跟公网浏览器基本一致，坏处是包体积会膨胀到一两百兆，内存占用也高。如果你的产品是大型桌面软件，用户对安装包大小不敏感，这个方案最省心。
第二类是系统自带网页容器，直接用操作系统提供的组件，好处是包体积几乎不增加、能自动跟着系统更新、硬件加速和系统集成做得最好，坏处是版本不可控，用户系统不更新你就得跟着兼容老版本，而且不同系统的内核还不一样，测试矩阵会翻倍。我做过的项目里，最头疼的就是这类方案下的“用户报了 Bug，但我这边复现不了”，最后发现是系统组件版本差了好几年。
第三类是轻量嵌入式方案，选用相对精简的引擎移植版，包体积能压到几十兆，内存也友好，适合资源受限的设备。代价是特性支持不全，某些现代 CSS 和 API 可能不支持，需要做降级。如果你的界面是自己写的、可控，这条路很划算；如果是要渲染任意外部网页，就要慎重了。
5. 常见问题与排查实录
5.1 高频问题速查表
下面这张表是我这些年攒下来的，基本都是文档里不会写、只能靠踩坑换来的：
| 现象 | 高概率原因 | 排查手段 | 处理方式 |
|---|---|---|---|
| 换内核后布局错位十几像素 | 滚动条占位策略不同 | 比较容器实际宽度与视口宽度 | 用覆盖式滚动条样式，或统一预留占位 |
| 某内核上字体发虚、行高不一致 | 字体渲染与度量策略不同 | 打印测量元素的 boundingRect | 显式指定行高和字体栈，不依赖默认值 |
| 动画只在某个内核掉帧 | 分层策略激进/保守 | 打开图层可视化看层数 | 手动控制分层，避免过度提升 |
| 日期解析结果不一致 | 非标准格式解析差异 | 用固定 ISO 格式做对照测试 | 一律显式解析，不依赖自动转换 |
| 表单控件样式完全跑偏 | 原生控件渲染差异 | 逐个内核截图对比 | 用自绘控件，或做完整样式重置 |
| 页面在低端设备上首屏超时 | 主线程长任务过多 | 分析长任务的时间分布 | 拆分任务、用空闲时间调度 |
| 内嵌视图内存持续上涨 | 页面未正确释放、监听未解绑 | 长时间运行观察堆曲线 | 显式销毁实例、解绑全局监听 |
| 同一段 JS 在不同内核耗时差三倍 | 对象结构不稳定导致优化退化 | 对比对象创建方式 | 固定对象形状、避免动态增删属性 |
5.2 几个我踩过的坑和独家心得
先说一个最贵的教训。早年做一个数据采集工具，用 UA 判断内核来做分支处理，逻辑是“如果是某个前缀就用 A 方案，否则用 B 方案”。上线后跑了几个月都正常，直到某次目标站点的页面结构变了，我的判断全部走错分支，采回来一堆空数据，还排查了两天才定位到。从那以后我给自己定了条规矩：任何跟引擎相关的分支，一律用特性检测，绝不用 UA 或版本号。宁可多写几行探测代码，也不要留一个会在半年后爆炸的定时炸弹。
第二个心得是关于渲染一致性测试的时机。很多人把兼容性测试放在功能开发完之后，这是反的。我现在的做法是项目一开始就把三个内核的自动化跑通，每天定时跑一遍冒烟用例，一旦有差异当天就能发现，定位成本极低。等到上线前再测，问题堆在一起，你根本分不清是新引入的还是历史遗留的。
第三个是关于性能优化的优先级判断。我见过太多人一上来就优化 JS 执行效率，实际上大部分页面的瓶颈根本不在那儿。正确的顺序是先看网络和资源加载，再看主线程的长任务分布，然后看布局和绘制的开销，最后才轮到 JS 计算本身。这个顺序是根据经验统计出来的，加载和渲染的时间占比通常远大于纯计算。先做对顺序，再谈优化技巧。
第四个是关于内嵌方案的版本冻结策略。如果你的产品要交付给客户长期使用，一定要把引擎版本钉死，并且保留一份完整的回归用例。因为你一旦跟着上游升级，就可能引入行为变化，而客户环境你没法控制。我见过一个项目因为随手升级了内嵌引擎，导致某个关键页面的打印分页全乱，最后不得不回滚重来。钉版本、留用例、升级前跑全量回归，这三件事缺一不可。
最后一个，关于怎么快速判断一个页面在某个引擎上会不会出问题。我的经验是看三个地方：一是滚动容器，涉及覆盖式滚动条还是占位式滚动条，直接影响宽度计算；二是文本排版，涉及字体度量、行高、断行规则，最容易出现细微差异；三是原生表单控件，涉及默认样式和交互行为，差异最大。这三块如果能对齐，剩下的部分出问题的概率就很低了。这个检查清单帮我省了大量时间，拿到一个新页面先过一遍这三点，基本能预判出大部分兼容性风险。
我自己在这个方向上折腾了几年，最大的感受是：浏览器引擎的选择从来不是一道纯技术题，而是一道成本与收益的匹配题。公网产品选生态最厚的，端侧产品选功耗最优的，内嵌产品选体积和可控性最合适的，实验性场景可以试试新生代但要留好退路。没有哪个引擎在所有维度上都强，关键是先搞清楚自己的约束条件，再去找最合适的那个。
