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