直接用 innerhtml 拼接长文本会失败，因为换行符\n被浏览器视为空格，导致语义结构丢失、屏幕阅读器误读、seo失效及移动端溢出，且不可嵌套块级元素，必须严格遵循语义化标签规则。
为什么直接用 innerHTML 拼接长文本会失败
因为浏览器不解析换行符，\n 在 HTML 中等同于空格，最终所有文字被压成一个 <p></p> 或干脆没 <p></p> —— 屏幕阅读器读作“一整段”，搜索引擎无法识别语义断点，移动端还会因超长 URL 或代码片段横向溢出。
- 后端模板（如 Jinja2）里写
{{ content }}而没套<p>{{ item }}</p>，等于放弃段落结构 - 前端 JS 用
el.innerHTML = text.split('\n').join('<br>')，只是视觉换行，不是语义分段 - AI 生成的 HTML 常漏闭合标签，比如
<p>第一段</p> <p>第二段</p>（第二个<p></p>被浏览器自动闭合，导致嵌套错乱）
<p></p> 必须包裹每一段，且不能嵌套块级元素
这是最常被忽略的硬性规则：<p></p> 是「段落」语义，不是「换行工具」。它天然排斥子元素为 <div>、<code><section></section>、甚至另一个 <p></p>。
- 错误写法：
<p></p> <div class="highlight">重点句</div>普通文字→ 浏览器会自动拆解为<p></p> <div>...</div> <p>普通文字</p> - 正确做法：用
<span></span>包裹内联强调内容，或把<div> 提到 <code><p></p>外层作为独立块 - 如果原始文本含标题、列表、引用等，必须用对应语义标签（
<h2></h2>、<ul></ul>、<blockquote></blockquote>），不能全塞进<p></p> -
<main></main>是否唯一且为直接子元素？多个<main></main>会让辅助技术迷失上下文 - 每个
<section></section>是否至少含一个<h2></h2>？否则 W3C 认为语义无效，SEO 权重归零 -
<p></p>的父容器是否为<article></article>、<section></section>或<main></main>？若直接挂在下，虽能渲染，但破坏内容层级
校验时重点盯这三处 DOM 结构
人工扫一眼不够，得看真实解析后的 DOM 树。尤其在 CMS 输出或 SSR 渲染后，容易出现「看起来对，实际错」的情况。
用 textContent 和 children.length 快速做基础校验
不需要完整 parser，几行 JS 就能暴露结构问题。适合集成进构建流程或 CMS 预发布检查。
const main = document.querySelector('main');
if (!main) console.warn('缺失 <main>');
const paragraphs = main.querySelectorAll('p');
paragraphs.forEach((p, i) => {
if (p.children.length > 0 && ![...p.children].every(el => el.tagName === 'BR' || el.tagName === 'SPAN')) {
console.error(`第 ${i + 1} 个 <p> 包含非法子元素：${p.children[0].tagName}`);
}
});
// 检查连续段落间是否有非预期的空段落
const emptyPs = [...paragraphs].filter(p => !p.textContent.trim());
if (emptyPs.length) console.warn(`发现 ${emptyPs.length} 个空 </p>
<p>，可能是模板插值错误`);
</p></main>
真正难校验的是语义合理性——比如该用 <blockquote></blockquote> 却写了 <p class="quote"></p>，这种只能靠人工或定制规则引擎。但上述三项已覆盖 90% 的生产环境崩溃点。
