HTML标签是触发浏览器解析引擎动作的指令，通过词法分析和语法分析构建DOM树，其解析过程受规范约束且容错机制各异。
HTML标签不是“写完就能用”的静态符号，而是触发浏览器解析引擎一系列动作的指令。它不直接决定页面长什么样，而是参与构建 DOM 树这一中间结构——后续样式、脚本、渲染全依赖这个树。
HTML解析器如何把<div><p>hello</p></div>变成树？
浏览器拿到 HTML 字节流后，并不逐行读取，而是走一套确定的解析流程：
- 先做词法分析（Tokenization）：把输入切分成
startTag（<div>）、text（"hello"）、endTag（</p>）等 token - 再语法分析（Parsing）：用栈维护当前上下文，遇到
<div>就新建节点压栈，<p>是子节点继续压，</p>弹出栈顶，</div>再弹一次 - 文本节点会被合并：连续的换行、空格、制表符在解析后通常只剩一个
Text节点，不是“原样保留” -
<table>类标签有隐式包裹逻辑：没写<tbody>，DOM 里也会自动补上，这是 HTML5 规范强制要求，不是浏览器“好心帮忙”
<head>里的标签为什么顺序重要？
<head> 不只是“放元信息的地方”，它的内容直接影响解析器行为和资源加载时机：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
<meta charset="UTF-8">必须靠前，否则前面字节可能被错误解码，导致乱码或解析中断 -
<link rel="preload">和<script defer>的位置决定预加载/延迟执行是否生效；放在<title>后比放在最末更早触发 -
<script>没加defer或async会阻塞 HTML 解析，此时栈中未闭合的元素可能挂载异常，比如<div><script>...</script><p>content</p></div>中的<p>可能被误挂到<head>下 -
<base>标签影响所有相对 URL 解析，必须在第一个<link>或<script>前声明，否则后续资源路径可能出错
为什么不同工具解析同一段 HTML 得到的 DOM 不一样？
浏览器原生解析器遵循 HTML5 Living Standard，但服务端工具（如 cheerio、BeautifulSoup、lxml）各自实现解析逻辑，差异集中在容错策略：
立即学习“前端免费学习笔记（深入）”；
-
cheerio默认按 XML 规则处理，遇到自闭合标签如<img/>会报错，而浏览器接受<img>、<img/>、<img />三种写法 -
BeautifulSoup的html.parser和lxml对缺失结束标签的推断不同：一个可能把<p>foo<div>bar</div>解成<p>foo</p><div>bar</div>，另一个可能让<div>成为<p>的子节点 - 标签大小写：浏览器不区分
<DIV>和<div>，但lxml在 strict mode 下会视为不同节点 - 属性值引号：
<a href=example.com>在浏览器中合法，在部分解析器中可能被截断为href=example
真正容易被忽略的，是解析器对“错误恢复”的定义——它不是 bug，而是规范的一部分。比如 <div><p><span>hello</div> 这种错嵌套，浏览器会主动闭合 <span> 和 <p> 再处理 </div>，而你用 DOMParser 或第三方库时，未必复现相同行为。别假设“HTML 文本一致 = DOM 一致”。
