应优先使用 parentElement 而非 parentNode，因其只返回元素节点，避免因文本节点导致的 classList 等属性访问错误；children 比 childNodes 更可靠，因其过滤空白节点；父子关系随 DOM 操作实时更新，需用 el.parentElement 判断是否存在。
怎么一眼看出哪个标签是哪个的父节点
浏览器不看缩进，但人靠缩进最快定位父子关系。盯住三处：下首层缩进的元素（如 <header>、<main>、<div class="container">）基本就是主干起点；缩进比上一行深，大概率是它的子节点；缩进相同，就是兄弟节点。
自闭合标签（如 <img>、<input>、<meta>）永远不可能是顶层，一定嵌在某个容器里——它没闭合标签，但必须有父节点。
常见错误现象：document.querySelector('p') 拿不到预期元素，其实是它被套在 <section> 里，而你查的是 <body> 直接子级；这时得用 document.body.children[0].children[1] 或更稳妥的 CSS 选择器。
parentNode 和 parentElement 到底该用哪个
parentNode 返回任意类型的父节点（可能是文本节点、注释节点），而 parentElement 只返回元素节点（即标签）。实际开发中，99% 的场景要的是父“标签”，不是父“节点”。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
- 用
node.parentNode后直接调用.classList，结果报错Cannot read property 'classList' of null——因为父节点可能是换行符生成的文本节点 - 遍历
childNodes时混入空白文本节点，误判子元素数量
建议统一用 parentElement 替代 parentNode，除非你明确需要处理文档注释或纯文本上下文。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
为什么 children 比 childNodes 更常用
childNodes 返回所有子节点，包括看不见的换行、空格、注释；children 只返回元素节点（即 HTML 标签），干净且可预测。
使用场景：
- 想统计一个
<ul>下有几个<li>，用ul.children.length，别用ul.childNodes.length（后者可能多出 2–3 个空白节点） - 循环操作子元素时，
for (let el of parent.children)比for (let node of parent.childNodes)少一堆类型判断 -
firstElementChild/lastElementChild是firstChild/lastChild的安全替代品
性能影响几乎为零，但代码健壮性提升明显——DOM 树里那些看不见的文本节点，是调试时最常被忽略的干扰源。
父子关系不是静态的，DOM 操作会实时改树
调用 appendChild()、removeChild()、replaceChild() 等方法后，父子关系立刻重连。这不是“模拟”，而是真实修改内存中的节点引用。
关键点：
- 移动一个已有元素（比如把
p从section移到aside），它自动脱离原父节点，成为新父节点的子节点——不需要手动清空旧引用 -
cloneNode(true)复制的是结构，但复制体没有父节点，需显式append()才能挂入树中 - 用
innerHTML = ''清空容器，会销毁所有子节点及其事件监听器，父子关系彻底断裂
真正难调试的，往往不是“找不到父节点”，而是“以为还挂着，其实已经被移走或替换了”。检查 el.parentElement 是否为 null，比猜更可靠。
