富文本编辑器中嵌套非法，浏览器解析时会自动拆解为扁平dom（如...），导致css选择器失效、js查询失败及ssr hydration不一致。
后台编辑器输出的 <p></p> 嵌套（比如 <p></p>
<div>...</div>
为什么富文本编辑器总爱往 p 里塞 div
多数后台编辑器（如 TinyMCE、Quill、UEditor、微信公众号编辑器）默认把用户粘贴的区块内容（图片+文字组合、卡片、引用块）包裹进 <p></p>，再往里硬塞 <div> 或 <code><section></section>。它们不校验 HTML 合法性，只管“看起来像段落”。结果就是源码看着正常，一渲染就断层。
-
<p></p> <div class="card">...</div>→ 实际 DOM 变成<p></p> <div class="card">...</div> <p></p> - CSS 选择器
p > div永远匹配不到，p { padding: 1em }对卡片无效 - JS 查询
document.querySelector('p .card')返回null - 服务端渲染（SSR）和客户端 hydration 时 DOM 结构不一致，触发 React/Vue 警告
前端运行时清洗：用 DOMParser 做最小干预修复
不能靠 CSS 强行“撑”回来，得在 JS 加载后、渲染前做一次结构归正。用 DOMParser 解析字符串并重写非法父级，比正则更可靠：
function fixPDivNesting(html) {
const parser = new DOMParser();
const doc = parser.parseFromString(html, 'text/html');
// 找所有被 p 包着的 div/section/article 等块级元素
doc.querySelectorAll('p > div, p > section, p > article, p > ul, p > ol').forEach(el => {
const parentP = el.parentElement;
const grandParent = parentP.parentElement;
// 把 div 提到 p 的同级，紧接在 p 后面
grandParent.insertBefore(el, parentP.nextSibling);
// 如果 p 为空或只剩空白，删掉它
if (!parentP.textContent.trim()) {
parentP.remove();
}
});
return doc.body.innerHTML;
}
- 不改原始 HTML 字符串，只操作解析后的 DOM 树，避免正则误伤属性或注释
- 只动
<p></p>下的非法子元素，不碰<p><span><strong></strong></span></p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8272" title="anything-to-html"><img src="https://img.php.cn/upload/skill/000/000/081/179195588450431.jpg" alt="anything-to-html" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill8272" title="anything-to-html" class="overflowclass">anything-to-html</a> <p class="overflowclass">将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。</p> </div> <a rel="nofollow" href="/xiazai/skill8272" title="anything-to-html" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>这类合法嵌套 - 保留原顺序：把
<div> 插到对应 <code><p></p>后面，视觉流不变 - 上线前加个兜底：如果
DOMParser不可用（极老 IE），降级为简单replace(/<p></p> <div>，但需配合后端补全 <h3>后端入库前拦截：用 <a style="color:#f60; text-decoration:underline;" title="html" href="https://m.php.cn/zt/15763.html" target="_blank">html</a>-validator 或 sanitize-html 预处理</h3> <p>前端修是补救，后端拦才是根治。CMS 或 API 接收富文本时，必须拒绝或重写非法结构：</p> <ul> <li>Node.js 用 <code>sanitize-html配置白名单：allowedTags: ['p', 'div', 'span', 'img'], allowedAttributes: {...}，并设exclusiveFilter: (frame) => frame.tag === 'p' && ['div', 'section'].includes(frame.text)主动剔除 - Python 用
bleach+ 自定义 cleaner，对<p></p>的child_tag做校验，遇到div就拆出并 wrap 成<div class="p-sibling"> <li>PHP 用 <code>HTMLPurifier，启用HTML.AllowedElements并禁用p的非法子元素类型 - 关键点：别只过滤 script/style，要检查嵌套合法性；W3C Validator 的
content model规则必须落地为代码逻辑 - TinyMCE：开
forced_root_block: false，关掉默认用<p></p>包裹粘贴内容的行为；用valid_children: '+body[div],+div[p|div|ul|ol]'显式声明容器资格 - Quill：重写
clipboard.dangerouslyPasteHTML，对粘贴内容做DOMParser预检，把p > div改成div > p - 微信公众号后台无法改源码？那就用浏览器插件（如 Tampermonkey）注入脚本，在编辑器 iframe 内监听
input事件，实时修正<p></p> <div> 片段 <li>所有方案都绕不开一点：编辑器的“所见即所得”是幻觉，它不等于“所存即合法”</li> <p>最麻烦的不是怎么修，而是很多人直到上线后 JS 报 <code>Cannot read property 'querySelector' of null才意识到——那个<p></p>根本没包住任何东西。
编辑器配置阶段就堵死源头
与其等输出再修，不如让编辑器从一开始就不生成错结构：
