正确处理CMS导出HTML需分两步：先用html.unescape()解码实体，再用BeautifulSoup解析并剥离标签；DOMParser仅在需清理Word残留时使用，且应复用实例以避免性能瓶颈。
用 html.unescape() 和 BeautifulSoup 处理 HTML 实体与标签混杂
内容管理平台（CMS）导出的长文本常同时含 HTML 标签（如 <p>、<strong>）和 HTML 实体（如 、"），直接用正则删 <.*?> 会把 <100> 这类合法数字误杀，也跳过实体还原。正确路径是分两步：先解码实体，再剥离标签。
常见错误是只做一步——比如只调 html.unescape()，结果 <p>Hello</p> 变成 <p>Hello</p>，但仍是字符串，没真正去除标签；或者只用 BeautifulSoup(html_str, "html.parser").get_text()，却漏掉 ' 这类数值实体，导致单引号变成乱码。
-
html.unescape()必须在BeautifulSoup解析前调用，否则get_text()输出里仍带符号 - 用
BeautifulSoup(..., "html.parser")而非"lxml"，避免在缺失闭合标签时抛异常（CMS 导出 HTML 常不规范） - 若需保留段落结构，改用
soup.find_all("p")提取文本，再"\n".join(p.get_text(strip=True) for p in ps)，比全量get_text()更可控
过滤富文本编辑器残留的 Word/粘贴脏节点
CMS 后台多用 contenteditable 编辑器，用户从 Word 粘贴或多次回车后，DOM 中会塞满空 <span>、带 style="mso-* 的标签、冗余 <div> 嵌套，甚至不可见的零宽空格 \u200b。这些在字符串层面看不见，但影响 len() 统计和 NLP 分词。
单纯靠正则或 get_text() 无法清理这类结构污染——get_text() 会合并相邻文本节点，但保留所有换行符和缩进空格；而 normalize() 只对真实 DOM 有效，对字符串无作用。
立即学习“前端免费学习笔记（深入）”；
- 必须走 DOM 路径：用
DOMParser().parseFromString(html_str, "text/html")构建文档，再遍历doc.body.childNodes过滤掉node.nodeType === 3 && node.textContent.trim() === ""的空文本节点 - 对
<font>、<o:p>、<!--[if ...]-->这类 Word 特有标签，不能只删开闭标签，要递归移除整个节点（node.remove()） - 提取纯文本前，先调
doc.body.normalize()，否则textContent里会出现多个连续空格或换行符
保留语义结构 vs 彻底去标签：按下游用途选策略
清洗目标不是“越干净越好”，而是匹配后续环节需求。例如，给 Elasticsearch 建索引需要紧凑纯文本，但喂给 LLM 的 prompt 需要保留段落和强调标记——全删 <strong> 可能丢失关键信息权重。
容易踩的坑是写死一个清洗函数到处复用：CMS 导出字段有的用于摘要展示（需保留 <p>、<h3>），有的用于统计字数（需彻底扁平化），混用会导致前端渲染错乱或指标偏差。
- 输出为纯文本（如搜索索引）：用
BeautifulSoup(...).get_text(separator=" ", strip=True)，separator设为空格而非换行，避免段落间多出空行 - 输出为受限 HTML（如安全渲染）：白名单保留
p、br、strong、em，用soup.find_all(lambda tag: tag.name not in WHITELIST)批量移除 - 注意
strip=True会删掉所有首尾空白，但 CMS 字段可能含刻意缩进（如代码块），此时应设strip=False再手动处理
性能瓶颈在 DOM 解析，别在循环里重复创建 DOMParser
对万级长文本字段批量清洗时，每条都走 new DOMParser().parseFromString() 会触发大量 GC，实测比纯 Python 方案慢 3–5 倍。这不是算法问题，而是浏览器 DOM 构建开销本身高。
很多人以为 “DOMParser 更准”，就无脑替换所有清洗逻辑，结果导出卡住半小时——其实多数 CMS 输出 HTML 结构简单，BeautifulSoup 已足够健壮，DOM 方案仅在必须处理 contenteditable 残留或需精确模拟渲染行为时才值得引入。
- Python 端优先用
BeautifulSoup(html_str, "html.parser")，它内部已处理大部分标签闭合错误，且支持features="lxml"加速（需额外装lxml） - JS 端若必须用 DOMParser，提前创建单例：
const parser = new DOMParser();，避免每次调用都新建实例 - 对纯文本提取场景，
DOMParser+textContent比innerText稳定——后者依赖样式计算，display:none元素内容会被丢弃
<!--[if gte mso 9]>...<![endif]-->）和 XML 命名空间声明（如 xmlns:o="urn:schemas-microsoft-com:office:office"）。它们不渲染，但会增大字符串体积、干扰正则匹配，且 BeautifulSoup 默认不识别这类 MS Office 特有语法，需显式启用 features="html5lib" 或前置正则清理。 
