浏览器解析HTML时并非照单全读，而是依据HTML5规范的tree construction算法逐字符构建DOM树，自动修正非法嵌套、缺失闭合等错误，生成的DOM结构可能与源码显著不同，且该修正不可逆、发生在JS执行前，后续所有操作均基于此修正后树。
浏览器怎么“猜”你本意？解析器的容错修正不是魔法
HTML 解析器不报错，不代表它照单全读。它在读取字符流的第一时间就启动一套确定性算法（HTML5 规范定义的 tree construction 算法），逐字符构建 DOM 树，遇到非法嵌套、缺失闭合、交叉标签时，不是跳过或中断，而是根据当前“格式化元素栈”和上下文状态，强制插入、移除或重排节点。
比如 <p>文字<div>区块</div></p>：解析器看到 <div> 进入 p 时，立刻判定违反 phrasing content 约束，于是自动闭合 p，再把 div 作为兄弟节点插入——最终 DOM 是 <p>文字</p><div>区块</div>，而非源码结构。
这种修正不可逆、不可禁用，且发生在 JS 执行前。所有后续操作（querySelector、CSS 选择器、事件委托）都基于这个“修正后”的树，不是你写的源码。
为什么 innerHTML += 会破坏结构？字符串拼接 ≠ DOM 追加
innerHTML 每次赋值都是独立解析：浏览器不会保留上一次解析的中间状态。写 el.innerHTML = '<p>开始' 后，DOM 中其实没有一个“半开”的 p 节点；它只是把字符串当作完整 HTML 片段解析，结果是 <p>开始</p>（自动补闭合）。
立即学习“前端免费学习笔记（深入）”；
再执行 el.innerHTML += '结束</p>'，相当于解析新字符串 '<p>开始</p>结束</p>'，第二个 </p> 因无匹配起始标签被忽略，最终得到 <p>开始</p>结束。
- 永远不要用
+=更新innerHTML来构造嵌套结构 - 需要流式拼接时，先在 JS 字符串变量里累积，最后一次性写入
innerHTML - 更安全的做法是用
insertAdjacentHTML('beforeend', ...)或DocumentFragment
服务端渲染（SSR）与 hydration 失败的根本原因
服务端生成的 HTML 字符串（如 <table><tr><td>1</td></tr></table>）中没写 <tbody>，但浏览器解析时强制插入，客户端 JS hydrate 时比对的是已修正的 DOM 树（含 tbody）和服务端原始字符串（不含 tbody），必然 mismatch。
这不是框架 bug，是 HTML 解析器行为与字符串比对逻辑的天然冲突：
-
document.querySelector('table tr')能命中，因为真实路径是table > tbody > tr -
innerHTML读取返回的是已补全的 HTML 字符串，不是原始输入 - 若需严格一致性校验，服务端必须模拟浏览器修正逻辑（如用
jsdom渲染），或放弃字符串比对，改用属性/数据驱动校验
Python 用 BeautifulSoup 做正规化时要注意什么？
BeautifulSoup(html, 'html.parser') 默认行为就是模拟浏览器容错逻辑：它会补全缺失标签、修正嵌套、标准化空格，输出的 str(soup) 已是“浏览器看到的样子”，不是原始 HTML。
但注意两点：
- 它不处理编码 BOM 或混合编码（如 UTF-8 + GBK），乱码会导致解析错位，必须提前统一解码
- 若原始 HTML 含
<script>内联代码，html.parser可能误将其中的</script>当作标签闭合——此时应换用lxml或显式设置features='lxml' - 不要依赖
find_all('p')的顺序去还原“作者本意”，因为p可能已被拆分或移动（如遇到div强制闭合）
真正难的从来不是“怎么修”，而是意识到：修正后的结构，已经不是你写的那个结构了。
