parentElement 无法验证嵌套合法性，仅返回修复后的父节点；须依 HTML 规范校验（如 p 不得含 div），或用 querySelectorAll + compareDocumentPosition 检测实际包含关系。
parentElement 链不能直接反映嵌套合法性
用 node.parentElement 向上查一层，只能告诉你“它父节点是谁”，但无法判断“这个父子关系是否符合 HTML 语义规范”。比如 p 下出现 div，parentElement 会正常返回那个 p，但实际浏览器已自动修正 DOM：把 div 踢出 p 外，导致你查到的“父节点”根本不是原始结构里的父节点。
真正要验的是“当前节点能否合法出现在其父节点中”，这得靠 HTML 规范约束，不是靠 DOM 树现状。
- 浏览器解析时已做容错修复（如
<p><div></div></p>→ 拆成<p></p><div></div><p></p>），parentElement查到的是修复后的结果 -
parentElement不报错、不警告，只返回一个 Element，但这个 Element 可能是浏览器“强塞”进去的 - 想验证嵌套合法性，必须对照 HTML 规范：比如
p只允许子节点为 phrasing content（span、strong、em等），不能含div、ul、p自身
用 parentElement + 白名单校验父子关系
在编辑器中做实时校验时，可结合 parentElement 和预设的“合法子元素白名单”快速判断。这不是万能方案，但对常见块级容器足够有效。
例如检查 node 是否能作为 parentElement 的合法子节点：
立即学习“前端免费学习笔记（深入）”；
- 先取
const parent = node.parentElement - 再查白名单：
const validChildren = { P: ['SPAN', 'STRONG', 'EM', 'CODE', 'A'], DIV: ['DIV', 'P', 'UL', 'OL', 'SECTION'], LI: ['P', 'SPAN', 'UL', 'OL'] } - 若
validChildren[parent.tagName]?.includes(node.tagName)为 false，则嵌套非法 - 注意大小写：所有
tagName都是大写，别漏了
避免只依赖 parentElement 的三个典型坑
编辑器场景下，光看 parentElement 容易掉进这些陷阱：
-
parentElement可能是document.body或document.documentElement，但这不代表嵌套合法——比如用户把td直接拖到body下，td.parentElement === document.body成立，但语义完全错误 - 文本节点（
Node.TEXT_NODE）的parentElement是它的包裹元素，但该包裹元素本身可能已被浏览器移位（如换行产生的#text被塞进意外位置） - Shadow DOM 内部节点的
parentElement返回的是 shadow host，而不是视觉上“包裹它”的宿主元素；此时parentElement链和语义层级完全脱钩
更可靠的替代方案：用 querySelectorAll 检查实际渲染结构
如果真要验证嵌套是否被浏览器悄悄改过，最稳的办法不是查父链，而是用选择器反向抓取，并比对位置关系：
比如验证某个 div 是否真的在 p 内部（而非被踢出）：
const p = document.querySelector('p');
const divInP = p.querySelectorAll('div');
// 如果 divInP.length === 0，但页面上明明有个 div 看起来在 p 里，
// 那说明它已被浏览器移出，嵌套不成立
- 用
document.querySelectorAll('p div')查所有被p包裹的div，结果为空就代表没成功嵌套 - 配合
node.compareDocumentPosition(otherNode)判断相对位置：若p.compareDocumentPosition(div) & Node.DOCUMENT_POSITION_CONTAINED_BY为 true，才说明 div 确实被 p 包含（IE8+ 兼容） - 注意：这种方法查的是最终渲染树，不是源码，所以它反映的是“浏览器认为合法的结构”，而非“你写的结构”
嵌套合法性本质是 HTML 解析阶段的产物，DOM API 只能告诉你结果，没法回溯原始意图。真正要防错，得在插入前拦截、用 schema 校验，而不是等节点挂载后再靠 parentElement 去猜。
