HTML解析器是检测p标签嵌套合法性的唯一可靠方式，因浏览器和html5lib等解析器会按HTML5算法自动修复非法嵌套，而正则或静态分析无法模拟tokenization与tree construction过程。
HTML解析器才是检测p标签嵌套合法性的唯一可靠方式
浏览器和标准HTML解析器（如html5lib、lxml、DOMParser）会自动修复非法的p嵌套——比如把<p><p>hello</p></p>重写为两个并列p。所以正则或简单字符串匹配根本无效，也得不到“是否合法”的真实答案。
真正能回答“这个p嵌套是否符合HTML规范”的，只有按HTML5算法执行tokenization和tree construction的解析器。
用html5lib捕获嵌套错误（Python）
html5lib在解析时不会抛异常，但会通过parser.parse()生成符合规范的树，你可以比对原始结构与解析后结构的差异来反推非法嵌套。更直接的办法是启用treebuilder的strict模式，并监听parser.errors：
import html5lib
<p>doc = "<p><p>nested</p></p>"
parser = html5lib.HTMLParser(tree=html5lib.getTreeBuilder("dom"))
document = parser.parse(doc)</p><h1>HTML5规范中，p是“中断元素”，禁止被p、div、address等包含</h1><h1>此处parser.errors会记录：["Start tag p seen when p element was already open"]</h1><p>for error in parser.errors:
if "p element was already open" in error[2]:
print("发现非法p嵌套")</p>-
parser.errors是元组列表，error[2]是人类可读的错误描述 - 该错误对应HTML5 spec中“acknowledging the nesting of
p”的规则 - 不依赖
lxml的XMLSyntaxError——因为HTML不是XML，<p><p>在XML里报错，在HTML里是“被修复”，不是语法错误
用DOMParser在浏览器中检测（JavaScript）
浏览器原生DOMParser同样不报错，但你可以检查解析后DOM结构是否“丢失了原始嵌套意图”：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
const doc = new DOMParser().parseFromString("<p><p>nested</p></p>", "text/html");
const ps = doc.querySelectorAll("p");
// 结果是2个同级p节点，而非1个包含另1个
console.log(ps.length); // 2
console.log(ps[0].contains(ps[1])); // false
- 如果原始字符串中存在
<p>直接包裹另一个<p>，解析后必然变成兄弟节点，contains()返回false - 注意避开
innerHTML赋值——它会走不同解析路径，且不暴露错误上下文 - 此法适用于测试用例断言，但无法区分“非法嵌套”和“合法换行导致的隐式闭合”（如
<p>text<p>more</p>）
为什么不用正则或querySelector静态分析？
因为HTML嵌套合法性根本不是静态语法问题，而是由解析算法动态决定的。例如：
-
<p><div>xxx</div></p>→div会强制闭合前面的p，最终生成两个节点 -
<p><span><p>inner</p></span></p>→ 外层p在遇到内层p时立即关闭，span被移到外面 - 所有这些行为都发生在tokenization阶段，跟标签文本位置无关
想靠innerHTML.match(/<p>.*?<p>/g)找嵌套，等于在解析前就假设了结构——而HTML5明确说“你不能假设”。真正的检测必须走到tree construction之后，看解析器到底建了什么。
最易被忽略的一点：即使你只关心p，也得完整解析整个文档片段，因为外部上下文（比如父元素是否是button或heading）会影响p的插入逻辑。
