因为浏览器解析HTML时会自动修正非法嵌套：p只允许phrasing content，遇到div即强制闭合p标签，生成的DOM结构与源码不同，JS和CSS操作均基于修正后的树。
为什么 p 里不能放 div，但写了浏览器也不报错？
因为浏览器根本不会按你写的结构去建 DOM——它在解析 HTML 字符串的第一时间就强制修正了。p 只允许包含 phrasing content（如 span、em、a、img），div 属于 flow content，一出现就会触发自动闭合。
常见错误写法：<p>文字<div class="card">区块内容</div></p>
实际解析结果（开发者工具里看到的）：<p>文字</p><div class="card">区块内容</div>
-
document.querySelector('p div')永远返回null - CSS 选择器
p > div完全不匹配 - 如果后续 JS 依赖
p包含该div来做位置计算或事件委托，逻辑直接失效
table 标签省略 tbody 为什么能正常显示？
不是“能省略”，而是浏览器必须补上。tbody 在 HTML 规范中是可选标签，但解析器要求表格结构合法，所以遇到 <table><tr><td>1</td></tr></table> 时，会自动插入 tbody 节点。
立即学习“前端免费学习笔记（深入）”；
这意味着：
-
document.querySelector('table tr')能查到，但真实 DOM 路径其实是table > tbody > tr - 用
innerHTML读取时，返回的是已补全的字符串，不是原始输入 - 服务端渲染（SSR）若比对 HTML 字符串一致性（比如做 hydration 校验），要注意这个差异不可绕过
交叉嵌套如 <b><i>text</b></i> 是不是 bug？
不是 bug，是 HTML5 解析器的容错设计。这类写法违反嵌套规范，但浏览器会基于“格式化元素栈”规则重排，目标是生成语义尽可能合理的 DOM。
例如：<b>hello <i>world</b> again</i>
实际解析近似为：<b>hello <i>world</i></b> again
- 这种修复只发生在
text/htmlMIME 类型下；若用application/xhtml+xml，直接报错中断渲染 - 虽然能显示，但会导致 CSS 选择器（如
b i）匹配范围偏移、无障碍阅读器朗读顺序异常 - W3C 验证器和 Lighthouse 仍会标为错误，不应作为开发习惯
实时拼接 HTML 时为什么 innerHTML += 会破坏结构？
因为每次赋值都是独立解析：浏览器不会记住上次 innerHTML 写了一半的 <p>，而是把新字符串当作完整片段重新解析。
错误示例：
el.innerHTML = '<p>开始'; // 3 秒后 el.innerHTML += '结束</p>';
结果是：<p>开始</p>结束</p>（第二个 </p> 因无匹配起始标签被忽略）
- 正确做法是维护一个字符串变量，在内存中拼完再一次性写入
innerHTML - 若必须流式更新，考虑用
createDocumentFragment或insertAdjacentHTML配合手动状态管理 - 尤其注意 SSR/CSR 混合场景，hydration 失败常源于这类 DOM 结构不一致
最易被忽略的一点：所有这些修正都发生在 HTML 解析阶段，JS 运行时看到的已经是“修复后”的 DOM。想还原原始结构？做不到。别在运行时猜用户写了什么，从源头保证嵌套合法才是成本最低的解法。
