soup.get_text() 默认输出难读，因其仅剥离标签、不识别语义换行，需用 separator="\n" 和 strip=true 控制格式，复杂结构须手动遍历节点处理。
直接用 soup.get_text() 提取 HTML 文本，大概率会得到一整块粘连、换行错乱、空格失控的“糊状文本”。这不是 bug，是默认行为 —— 它只负责剥离标签，不负责理解语义。
为什么 soup.get_text() 默认输出难读？
因为 soup.get_text() 不区分段落、标题、列表或换行符来源。它把所有文本节点按 DOM 顺序拼接，中间只用单个空格分隔（除非你显式指定 separator）。比如 <p>第一段</p>
<p>第二段</p> 会被压成 “第一段 第二段”，而 <br> 或 <div> 嵌套产生的换行则可能被忽略或保留为多余空行。<ul>
<li>默认不识别语义换行：标题后、段落后、<code><li> 之间不会自动加换行
strip=True 只清理首尾空白，不处理中间连续空格或制表符<div> 的结构信息完全丢失，变成扁平字符串<h3>用 <code>separator 和 strip 控制基础格式
这是最轻量但最关键的调整点。不要跳过参数，尤其在批量处理时。
- 用
soup.get_text(separator="\n", strip=True)让不同标签间的文本至少换行，比空格更易读 - 若想模拟段落间距，可设
separator="\n\n"，但注意：它对每个文本节点都生效，可能产生空行爆炸 -
strip必须设为True，否则每段前后带大量缩进和换行，后续清洗成本翻倍 - 避免用
separator=" "（默认值）处理中文内容 —— 中文无空格分词，会导致“标题正文”连成一词
需要保留列表/标题结构？别只靠 get_text()
get_text() 是“全有或全无”的提取器，它不保留任何结构上下文。如果目标是让“<h2>小节标题</h2>
<p>正文内容</p>”变成带缩进或标记的文本（如 “## 小节标题\n正文内容”），就得手动遍历节点。
- 优先用
soup.find_all(['h1','h2','h3','p','li'])分类提取，再逐个调用.get_text(strip=True) - 对
<li>节点，可前缀"- "；对<h2></h2>，前缀"## "，再拼接 - 警惕
<table>：直接 <code>get_text()会把行列内容挤成一行，必须单独处理<tr>/<code><td> <li>如果 HTML 含 <code><script></script>或<style></style>，记得先soup.find('script').decompose()，否则脚本内容也会被提取 -
—等实体不会自动解码 —— 用html.unescape()预处理原始字符串 - 由
fetch()或React动态插入的内容，requests拿到的 HTML 里根本不存在，BeautifulSoup无法提取 - 若必须处理动态内容，得换方案：用
Playwright或Selenium启动真实浏览器，再取page.inner_text()或document.body.innerText - 正则临时救急可以，但别用
re.sub(r']+>', '', html)处理含onerror="alert('<script>')"</script>这类属性的 HTML —— 会误删内容
遇到 JS 渲染内容或实体字符怎么办？
纯 BeautifulSoup 解析的是原始 HTML 字符串，不是浏览器渲染后的结果。这意味着：
真正麻烦的从来不是“怎么去掉标签”，而是“去掉之后，用户还能不能一眼看懂这段文字原本的结构意图”。get_text() 是起点，不是终点；参数不是可选项，是必调项；而 JS 渲染、实体编码、嵌套语义，这些点漏掉一个，后面就得花三倍时间补数据清洗逻辑。
