浏览器不报错≠HTML合法，解析器会静默修正非法嵌套（如<p><div></div></p>），强制闭合<p>并移出<div>，导致DOM与源码不一致，引发querySelector失效、CSS失配、SSR hydration失败等问题。
浏览器不报错 ≠ HTML 合法
HTML 解析器遇到非法嵌套（比如 <p><div></div></p>）根本不会抛错，而是立即按规范强制修正 DOM：遇到 <div> 就闭合当前 <p>，后续内容被扔到外面。你写的结构和 Elements 面板里看到的 DOM 完全不是一回事。
常见后果包括：document.querySelector('p div') 永远返回 null、CSS 选择器 p > div 失效、SSR hydration 校验失败、无障碍阅读器朗读顺序异常。别信“能显示就行”，得看真实 DOM。
- 打开 Chrome DevTools → Elements 面板，留意灰色、斜体或带删除线的节点——那是被静默修正过的痕迹
- 禁用所有 CSS 后观察块级元素是否塌陷或错位，这是父容器被意外截断的典型信号
-
<p>只允许 phrasing content（<span>、<a>、<img>等），<div>、<h2>、<ul>全都不合法
W3C Validator 是唯一可信的合法性判据
VS Code 插件或格式化工具只能提示缩进/配对问题，但无法判断语义合法性。validator.w3.org 是唯一依据 HTML Living Standard 做语法级校验的权威工具，它会精准指出 “Element div not allowed as child of element p” 这类错误。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 粘贴完整 HTML 字符串（不要只贴片段），它会定位首个错误行——优先修复这个，因为后续错误常是前序纠错引发的连锁反应
- 对 SSR 场景，务必把服务端生成的 HTML 字符串丢进去校验，不能只验客户端渲染后的 DOM
- 遇到
Element img is not closed这类警告必须处理，<img src="x"></img>是严重错误，会被解析为两个<img>标签
table / ul / form 的嵌套边界最容易踩坑
这些标签有硬性子元素约束，违反后浏览器的纠错逻辑极不可控：
-
<table>看似能省略<tbody>，但实际 DOM 路径永远是table > tbody > tr；document.querySelector('table tr')能查到，只是因为 selector 自动穿透了<tbody>，但innerHTML返回的是补全后的字符串，SSR hydration 时比对原始字符串必失败 -
<ul>和<ol>的合法子元素只有<li>；<p>Item</p>直接放在<ul>里会导致浏览器拆成<ul></ul><p>Item</p><ul></ul>，序号重置、querySelectorAll('ul li')漏数据 -
<form>内部若出现未包裹在<fieldset>或<div>中的<p>，可能被纠错为<form><p>...</p></form>或直接移出<form>，导致提交时字段丢失
自动化修复要慎用，人工校验仍是关键环节
CodePen 的 Debug Mode、在线 HTML Beautifier 或 VS Code 的 Auto Close Tag 插件，只能帮你补闭合、调缩进，但无法识别语义错误。比如它会把 <p><div>xxx</div></p> 格式化成缩进正确的样子，却不会告诉你这本身就是非法结构。
真正有效的实践组合是：
- 写完一段 HTML 后，立刻粘到 W3C Validator；红标不消失，不提交代码
- VS Code 开启
editor.matchBrackets+ 安装Auto Rename Tag，光标停在<div>上就能高亮匹配项，避免手动数漏 - 模板字符串拼接（如 EJS、Lit）中尤其危险，建议加注释标明层级：
<!-- end user-card -->，而不是依赖自动补全
最常被忽略的点是：浏览器纠错行为在 text/html 和 application/xhtml+xml 下完全不同，前者容忍交叉嵌套（如 <b><i>text</b></i>），后者直接报错中断渲染——别拿开发环境的“能跑”当生产环境的“合法”。
