html解析器嵌套于渲染引擎中，blink与webkit核心逻辑一致但触发条件、容错策略及管线衔接存在差异，直接影响怪异模式、标签闭合、自定义元素识别等行为。
HTML解析器本身不独立存在，它始终嵌套在渲染引擎中运行；Blink和WebKit的HTML解析器核心逻辑高度一致，但触发条件、错误容错策略和后续渲染管线衔接方式存在关键差异——这些差异直接影响页面是否进入怪异模式、标签闭合行为、自定义元素识别时机等实际表现。
DOCTYPE如何决定Blink与WebKit的解析起点
浏览器在读取字节流的前1024字节内就完成doctype检测，且不依赖完整DOM构建。Blink与WebKit都遵循同一套doctype判定规则，但对“不规范声明”的容忍度不同：
在两者中均强制触发标准模式，这是唯一被全平台无条件认可的写法- 带空格或换行的
（注意DOCTYPE前多一个空格）：WebKit会降级为近乎标准模式，Blink则直接进入怪异模式 - 缺失doctype或仅写
：Blink在Chromium 110+后默认启用“quirks mode fallback”，而WebKit仍沿用旧式IE5盒模型逻辑 - XML声明
<?xml version="1.0"?>前置时：Blink会忽略并继续扫描doctype，WebKit可能提前终止解析并报XML declaration not at start of document
标签解析与自动闭合行为的细微差别
Blink和WebKit共享KHTML时代继承来的HTML解析算法（如“插入模式”栈），但在边缘场景下执行路径已分叉：
-
<p></p> <div>content</div>：Blink会将<div>视为<code><p></p>的非法子元素，立即闭合<p></p>再开启<div>；WebKit则允许<code><div>嵌套进<code><p></p>，直到遇到才统一回退修正 - 自闭合标签如
<img>：Blink严格按HTML5规范只认<img>，/>被忽略；WebKit在iOS 16.4之前仍保留对XHTML风格的兼容处理 -
<script></script>内未转义的：Blink使用字符流预扫描，在JS字符串中出现也会中断解析；WebKit依赖更保守的token边界判断，部分情况下能继续 -
<meta charset="utf-8">放在<title></title>之后：Blink会直接忽略，回退到HTTP响应头或BOM探测；WebKit仍尝试应用，但可能因已开始解析而失效 - 同时存在
Content-Type: text/html; charset=gbk与<meta charset="utf-8">：Blink以HTTP头为准（除非响应头缺失charset参数）；WebKit以meta为准（只要它出现在前1024字节） - 未声明charset且文档含BOM：Blink在Windows平台可能误判为UTF-16LE，WebKit更倾向UTF-8+BOM校验
- Blink中
document.write()在DOMContentLoaded后调用会强制清空整个document并重建解析器，WebKit则抛出DOMException并静默失败 - 自定义元素升级时机：Blink在
customElements.define()后立即触发connectedCallback，WebKit需等待当前microtask队列清空 - HTML模板解析：Blink对
<template></template>内容采用惰性解析，首次content.cloneNode()才构建子树；WebKit在模板挂载时即完成全部解析
meta charset位置与编码探测冲突
字符编码声明必须出现在前1024字节内，且优先级高于HTTP头。Blink与WebKit在此处的决策逻辑差异最易引发乱码：
开发者真正该关注的兼容性断点
不要试图在JS层模拟解析差异，那些都是表象。真正影响交付质量的是底层渲染管线衔接点：
这些差异无法靠polyfill抹平，必须在构建时通过userAgent特征检测（如检查navigator.userAgent.includes("AppleWebKit") && !navigator.userAgent.includes("Chrome")）做分支处理。最危险的是假设“解析器输出DOM树就结束了”——实际上Blink的Layout阶段会反向修改DOM（比如表格行的隐式<tbody>插入），而WebKit在Parse阶段就已完成这类修正。</tbody>
