富文本编辑器中<p>嵌套<div>非法，浏览器解析时会自动拆解为扁平DOM（如<p></p><div>...</div><p></p>），导致CSS选择器失效、JS查询失败及SSR hydration不一致。
后台编辑器输出的 <p> 嵌套（比如 <p><div>...</div></p>）不是“样式没调好”，而是 HTML 解析器在第一步就把它废掉了——你写的结构根本不会进 DOM。
为什么富文本编辑器总爱往 p 里塞 div
多数后台编辑器（如 TinyMCE、Quill、UEditor、微信公众号编辑器）默认把用户粘贴的区块内容（图片+文字组合、卡片、引用块）包裹进 <p>，再往里硬塞 <div> 或 <section>。它们不校验 HTML 合法性，只管“看起来像段落”。结果就是源码看着正常，一渲染就断层。
-
<p><div class="card">...</div></p>→ 实际 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><span><strong>这类合法嵌套 - 保留原顺序：把
<div>插到对应<p>后面，视觉流不变 - 上线前加个兜底：如果
DOMParser不可用（极老 IE），降级为简单replace(/<p><div/gi, '<div')，但需配合后端补全
后端入库前拦截：用 html-validator 或 sanitize-html 预处理
前端修是补救，后端拦才是根治。CMS 或 API 接收富文本时，必须拒绝或重写非法结构：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- Node.js 用
sanitize-html配置白名单：allowedTags: ['p', 'div', 'span', 'img'], allowedAttributes: {...}，并设exclusiveFilter: (frame) => frame.tag === 'p' && ['div', 'section'].includes(frame.text)主动剔除 - Python 用
bleach+ 自定义 cleaner，对<p>的child_tag做校验，遇到div就拆出并 wrap 成<div class="p-sibling"> - PHP 用
HTMLPurifier，启用HTML.AllowedElements并禁用p的非法子元素类型 - 关键点：别只过滤 script/style，要检查嵌套合法性；W3C Validator 的
content model规则必须落地为代码逻辑
编辑器配置阶段就堵死源头
与其等输出再修，不如让编辑器从一开始就不生成错结构：
- TinyMCE：开
forced_root_block: false，关掉默认用<p>包裹粘贴内容的行为；用valid_children: '+body[div],+div[p|div|ul|ol]'显式声明容器资格 - Quill：重写
clipboard.dangerouslyPasteHTML，对粘贴内容做DOMParser预检，把p > div改成div > p - 微信公众号后台无法改源码？那就用浏览器插件（如 Tampermonkey）注入脚本，在编辑器 iframe 内监听
input事件，实时修正<p><div>片段 - 所有方案都绕不开一点：编辑器的“所见即所得”是幻觉，它不等于“所存即合法”
最麻烦的不是怎么修，而是很多人直到上线后 JS 报 Cannot read property 'querySelector' of null 才意识到——那个 <p> 根本没包住任何东西。
