parentelement 是最稳妥的选择，它只返回 element 类型节点或 null，避免 parentnode 可能返回 document、null 或文本节点导致的类型错误和空指针问题。
parentElement 是最稳妥的选择，parentNode 容易踩空或类型错误，别直接链式调用。
为什么不能无脑用 parentNode
parentNode 返回的不一定是元素节点——它可能是 Document、DocumentFragment 或 ShadowRoot。比如 的子元素调用 .parentNode，得到的是 document 对象，不是 Element；此时若接着写 .parentNode.className，就会报 TypeError: Cannot read property 'className' of #document。
- 刚创建但还没插入 DOM 的元素（如
document.createElement('div')），parentNode为null -
parentNode可能指向文本节点的父级（比如包裹文字的<span></span>），而你真正想要的是容器<div> <li>事件委托中常写 <code>event.target.parentNode，但event.target可能是文本节点或伪元素，它的parentNode并非业务逻辑中的“父容器” - 它天然跳过
Document和DocumentFragment，避免类型错误 - 未插入文档时也返回
null，行为一致，便于统一判空：if (el.parentElement) { ... } - 但要注意：如果目标元素是
，它的parentElement就是null（因为的父级是document，不是元素）
parentElement 更安全，但也要注意边界
parentElement 只返回 Element 类型节点，不存在时返回 null，不会返回 Document 或文本节点，适合绝大多数“找 HTML 标签父级”的场景。
需要向上找多层时，别手写 while 循环
比如从任意嵌套的 <li> 找到顶层 <ul class="list"></ul> 下的直接子 <li class="list-item">，用 closest() 比循环更可靠：
const topLi = el.closest('*:not(.list-item) > .list > .list-item');
这个选择器确保只匹配「祖父不是 .list-item、父是 .list、自身是 .list-item」的元素。
-
closest()在 IE 中不支持，需 polyfill 或降级为while+parentElement（不是parentNode） - 手动遍历时，必须用
parentElement判空并检查类名，而不是parentNode+classList - 避免用
parentNode.tagName这类写法——parentNode可能是document，没有tagName
真正容易被忽略的点：不是所有“父级”都该用同一个 API。你要的是标签？用 parentElement。你要的是结构关系（比如含文本节点的完整树）？才考虑 parentNode，且必须先做类型判断。
