BeautifulSoup的prettify()仅按嵌套缩进美化，不修复缺失闭合、错位嵌套等破损结构，反而可能破坏浏览器容错渲染；应优先用lxml.html.fromstring()+tostring()归一化HTML。
为什么直接用 BeautifulSoup 的 prettify() 会越洗越乱
它只按标签嵌套缩进，不修复缺失闭合、错位嵌套或非法嵌套（比如 <p></p> 里套 <div>），反而可能把原本能被浏览器容错渲染的 HTML 变成解析失败的结构。真实网页中大量存在未闭合的 <code><meta>、孤立的
<br>、混在文本里的
，prettify() 对这些无感，还可能把内联样式或 script 中的换行也格式化掉，破坏原始语义。
真正要做的不是“美化”，是“归一化”：让 HTML 回到浏览器实际解析时的状态。建议优先走 lxml.html.fromstring() + tostring() 这条链：
-
lxml.html.fromstring()会自动修复常见破损（补闭合标签、修正嵌套层级、丢弃非法子节点） - 传入
recover=True（默认开启）可处理严重破损文档 - 后续调用
etree.tostring(doc, encoding='unicode', method='html')输出干净、扁平、合法的 HTML 字符串
如何安全剥离 script/style 并保留有意义的文本结构
直接用 decompose() 或正则删 <script></script> 很危险：某些页面把 JSON 埋在 <script type="application/ld+json"></script> 里，删了就丢数据；有些 CSS 里含伪元素内容（::before { content: "✓" }），视觉上是关键符号，纯文本提取会漏掉。
更稳妥的做法是分层处理：
立即学习“前端免费学习笔记（深入）”；
- 先用
lxml.html.clean.Cleaner()配置白名单：scripts=True,style=True, 但设safe_attrs_only=False，避免误杀带data-属性的容器 - 对残留的
<script></script>标签，单独检查elem.get('type')—— 若为"application/ld+json"或"text/javascript"且内容含"@context"，跳过删除，转存到元数据字典 - 用
doc.text_content()提取纯文本前，先调用doc.make_links_absolute(base_url)，防止相对路径链接在后续分析中失效
lxml 和 html5lib 在脏 HTML 解析上的关键差异
lxml 快、内存低，但对“浏览器怎么解析”的模拟较弱；html5lib 完全照搬 HTML5 规范，能还原 <table> 中缺失 <code><tbody> 的自动补全、<code><a></a> 嵌套 <p></p> 的自动拆解等行为，但慢 3–5 倍，且输出的是 DOM 树，需额外转成 lxml 对象才能用 XPath。
选型建议看场景：
- 抓新闻正文、电商详情页这类结构较稳的页面 → 用
lxml.html.fromstring(html, parser=lxml.html.HTMLParser(recover=True)) - 抓用户生成内容（UGC）页，如论坛帖子、评论区，含大量随意粘贴的 HTML 片段 → 改用
html5lib.parse(html, treebuilder='lxml')，再转lxml.html.document_fromstring(str(doc)) - 若发现
lxml解析后//img/@src抽不到图，但浏览器能显示 → 大概率是srcset或懒加载导致，此时不要怪解析器，该查@data-src或执行 JS
清洗后仍出现乱码或空格爆炸？检查这三处编码源头
常见现象是中文变 ，或段落间冒出大量 \xa0、\u200b（零宽空格）。这不是清洗问题，是编码流断裂：
- 原始 HTTP 响应头没声明
charset，而网页<meta charset="gbk">鍙堟櫄浜庤В鏋愬櫒璇诲彇 鈫
