优先用 beautifulsoup 定位语义化容器（如、或含content/post等类的div）再调用get_text(separator="\n", strip=true)，并预先decompose script/style/nav等干扰标签，同时正确设置响应编码。
直接用 BeautifulSoup 的 get_text() 加合理选择器，比正则或手动 DOM 操作更稳——尤其面对不规范 HTML、嵌套广告、JS 注入内容时，正则容易漏掉或误删。
用 BeautifulSoup 定位主体区域再提取
多数网页正文藏在语义化容器里（如 <main></main>、<article></article>、<div class="content">），硬通货是先缩小范围，再调用 <code>get_text()，避免把页脚导航、侧边栏、广告文案一起拖进来。
- 优先尝试：
soup.find("main") or soup.find("article") or soup.find("div", class_=re.compile(r"content|post|entry|body")) - 若目标结构固定（比如教育平台的
<div class="dnevnik-lesson__task">），直接写死 CSS 选择器：<code>soup.select("div.dnevnik-lesson__task") - 提取后加参数控制格式：
.get_text(separator="\n", strip=True)——separator="\n"让段落间有换行，strip=True去首尾空格，比默认行为更干净 - 提取前先删掉：
for tag in soup(["script", "style", "nav", "footer", "header", "aside"]): tag.decompose() - 如果页面含大量图标标签（如
<i class="icon-download"></i>），它们虽无文本但占 DOM 位置，不影响get_text()，无需额外处理 - 注意：不要用
extract()，它返回被移除节点；decompose()更彻底，连节点对象都销毁，内存更友好 - 拿到
response后立刻设编码：response.encoding = response.apparent_encoding or "utf-8"，比硬写"utf-8"更可靠 - 若仍乱码，检查
response.headers.get("content-type")是否含charset=gbk类信息，并优先采用它 - 本地读 HTML 文件时，显式指定
encoding="utf-8"或encoding="gbk"，别依赖系统默认 -
innerText在无 DOM 环境（如 Python 后端）根本不可用 - 正则无法处理自闭合标签（
<br>）、属性含>的情况（<div data-value="a>b">） <li> <code>BeautifulSoup自动修复缺失闭合标签、转义字符、跳过注释——这些全是正则和原生 DOM 解析器不会帮你兜底的点
过滤干扰节点再提取
即使选对了父容器，里面仍可能混着 <script></script>、<style></style>、<nav></nav>、<footer></footer> 这类非文本节点，它们的 get_text() 结果会污染输出。
处理编码与乱码问题
中文提取失败，90% 是编码没对齐。不是所有网页都声明 UTF-8，requests 默认按 ISO-8859-1 解码，一读就变“文本”。
为什么不用 document.body.innerText 或正则？
浏览器控制台跑 document.body.innerText 看起来快，但它依赖页面已完整渲染 + JS 执行完毕；而服务端解析 HTML 字符串时，JS 根本没运行，结果天差地别。正则更危险：re.sub(r"]+>", "", html_str) 会吃掉注释里的文本、破坏实体（如 变成 ）、误杀含 > 的 JS 字符串。
真正难的不是“怎么取”，而是判断“该从哪取”：同一套代码在新闻站、论坛帖、教务系统里，主体选择器可能完全不同；而一旦选错容器，后面所有清洗都白做。所以第一步永远该是人工 inspect 几个典型页面，确认结构共性，再写选择器。
