DOMParser无法检测HTML嵌套语义错误，因其宽容解析会自动修复非法结构；需手动遍历节点并依据HTML规范的内容模型校验，或使用parse5/jsdom配合验证工具。
DOMParser 解析 HTML 字符串时根本不会报语法嵌套错误
DOMParser 的 parseFromString() 方法对 HTML 是“宽容解析”——它会自动修复不合法的嵌套（比如 <div><p><div></p></div>），返回一个看似正常的 Document，但原始结构已被重写。你无法靠它发现 <li> 直接包 <div>、<p> 套 <h1> 这类语义/嵌套违规，因为浏览器解析器默认就允许（并修正）它们。
真正能暴露这类问题的是 HTML 验证器（如 W3C Validator）或静态分析工具，不是 DOMParser。
想用 DOMParser 检查嵌套，只能靠手动遍历 + 规则校验
你需要在解析后主动遍历节点，对照 HTML 规范中元素的 content model（比如 <ul> 只允许子节点为 <li>、<script>、<template>），逐个判断是否越界。
- 用
document.querySelectorAll('*')获取所有元素，再按父节点类型分组检查子节点 - 重点关注：
<ul>/<ol>下非<li>元素、<table>内直接放文本或<div>、<p>内嵌<h1>–<h6>等 - 注意：
innerHTML或textContent中的原始字符串已丢失，DOMParser 不保留“错误位置”，只能定位到节点层级
常见误判场景：自定义标签、SVG、MathML 混用
DOMParser 会把 <my-component> 当作合法未知元素，但如果你的校验规则只覆盖 HTML 标准元素，就会漏掉它内部的嵌套问题；SVG 和 MathML 子树（如 <svg><g><div></div></g></svg>）的嵌套规则完全不同，需单独处理命名空间和内容模型。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
- 用
node.namespaceURI区分http://www.w3.org/1999/xhtml（HTML）、http://www.w3.org/2000/svg（SVG）、http://www.w3.org/1998/Math/MathML（MathML） - 对 SVG 元素，禁用 HTML 内容模型检查（例如
<g>允许任意子元素） - 避免用
element.tagName === 'DIV'判断，改用element.localName === 'div'（大小写不敏感且兼容 XHTML）
替代方案更靠谱：用 parse5 或 jsdom 做可配置解析
DOMParser 是浏览器内置 API，不可定制错误行为；而 parse5（纯 JS HTML 解析器）支持传入 treeAdapter 和自定义 errorHandler，能捕获“unexpected-start-tag-in-table-context”这类规范级错误；jsdom 则可在 Node.js 环境模拟完整 DOM，并通过 console.error 拦截解析警告。
例如用 parse5：
const parse5 = require('parse5');
const document = parse5.parse('<ul><div></div></ul>', {
treeAdapter: parse5.treeAdapters.default,
onError: (error) => console.warn(error.code, error.startLine, error.startCol)
});
输出：MISSING_END_TAG_NAME 1 5（提示 <div> 缺闭合标签），但注意：它仍不会报“<div> 不该在 <ul> 里”——那是验证层的事，不是解析层的事。
真正要捕获嵌套语义错误，得把解析结果喂给 html-validate 或自己实现基于 WHATWG HTML Living Standard 的 content model 检查器；DOMParser 只是起点，不是终点。
