应优先使用parentelement，因其只返回元素节点，避免因parentnode返回文本、注释或document节点导致的null错误；children同理优于childnodes，专用于获取子元素。
直接用 parentNode 和 parentElement 就能拿到父节点，但选哪个得看你要什么类型
绝大多数时候你想要的是“上一级 HTML 标签”，不是换行符或注释节点。这时候必须用 parentElement —— 它只返回元素节点（即带标签名的 DOM 节点），而 parentNode 可能返回 #text、#document 甚至 null。
常见错误现象：event.target.parentNode.classList.add('active') 报错 Cannot read property 'classList' of null 或 of #document，就是因为 parentNode 指向了 document 节点，或者目标节点还没插入 DOM。
- 刚创建未挂载的节点：调用
parentNode返回null；parentElement同样是null，但语义更明确 - body 直接子元素：其
parentNode是document.documentElement（即），但parentElement在这种情况下也有效 - 文本节点（如换行）作为子节点时：
parentNode可能是你想要的容器，但后续链式操作会崩；parentElement自动跳过非元素节点，更安全
children 比 childNodes 更可靠，尤其在遍历子元素时
如果你要找某个 <ul></ul> 下的全部 <li>，别用 childNodes —— 它会把换行、空格、注释全算进去，返回一个混着 Node.TEXT_NODE 的 NodeList。而 children 只返回元素节点，返回值是 HTMLCollection，可直接用 [0]、.length、for...of。
使用场景：动态生成菜单、表格行操作、表单字段批量处理。
-
el.children：返回第一层子元素，不含文本节点，IE9+ 全支持 -
el.childNodes：返回所有子节点，需手动过滤node.nodeType === Node.ELEMENT_NODE（值为 1） -
el.firstElementChild/el.lastElementChild：比firstChild/lastChild更准，避免取到空白文本节点
兄弟节点要用 previousElementSibling 和 nextElementSibling
previousSibling 和 nextSibling 极易踩坑：只要两个标签之间有换行或空格，它们就指向一个 #text 节点，而不是你预期的上一个/下一个 <li> 或 <div>。
<p>示例：点击某个按钮，高亮它前一个同级卡片 —— 如果用 <code>btn.previousSibling，大概率拿到的是换行符节点，.className 会报错；换成 btn.previousElementSibling 就稳了。
- 兼容性没问题：
previousElementSibling/nextElementSiblingIE9+ 支持 - 返回值是
null而不是undefined，适合直接做存在性判断：if (el.previousElementSibling) { ... } - 不推荐用
parentNode.children再遍历索引找兄弟，性能差且易受 DOM 动态变化干扰
父子关系不是静态快照，DOM 变动后引用会实时更新
你存了一个 const parent = el.parentElement，之后如果这个 el 被移出文档或移动到其他容器，parent 不会自动更新 —— 它只是当时那个时刻的引用。但如果你反复调用 el.parentElement，每次都会按当前 DOM 状态计算。
容易被忽略的地方：事件委托中缓存父容器引用后，若后续通过 innerHTML 或 replaceChildren 重写了父节点内容，旧引用仍指向原节点，但它的子树可能已失效。
- 不要长期缓存
parentNode或parentElement引用用于后续 DOM 查询，除非你能确保结构不变 - 涉及动态插入/删除的逻辑，优先每次现场查：
event.target.closest('.card')比缓存父节点更鲁棒 -
el.parentElement返回的是实时 DOM 中的父元素，但不会触发重排或重绘，性能无负担
