优先用innerText，因它返回用户实际看到的可见文本，受CSS隐藏、空白合并等渲染逻辑影响；textContent则返回所有原始文本节点内容，不考虑样式，适用于数据清洗场景。
用 innerText 还是 textContent？关键看是否要模拟渲染效果
浏览器中提取“可见文本”，本质是在问：要不要考虑 CSS 隐藏、伪元素、换行折叠等渲染层逻辑？innerText 会受 display: none、visibility: hidden 影响，跳过不可见节点，并自动合并空白；textContent 则原样返回所有文本节点内容（包括注释里的文字、script 标签内代码），不关心样式。
多数场景下你要的是用户实际看到的文本——比如从富文本编辑器输出里取摘要、解析 tooltip 的 title 值、或清理表单提交前的 HTML 字段。这时应优先用 innerText，它更贴近真实浏览体验。
- 若目标是纯数据清洗（如日志归档、后端入库），且需保留所有原始字符（含空格、换行、注释），用
textContent -
innerText在 IE8+ 和现代浏览器都可用，但注意它会触发重排（re-flow），高频调用需节流 - 服务端环境（如 Node.js）没有
innerText，必须用textContent或 DOMParser +body.innerText模拟
DOMParser 解析 HTML 字符串时，该读 doc.documentElement.innerText 还是 doc.body.innerText？
当你拿到一段 HTML 片段（比如 <div><i>Hello</i> <span>World</span></div>），用 DOMParser 解析后，文档结构可能带 <html><head></head><body>...</body></html> 外壳，也可能直接是 <div>... 根节点。
安全写法是统一取 doc.documentElement.innerText：它覆盖两种情况——有 <html> 包裹时走根元素，没包裹时 documentElement 就是那个 <div>，仍能正确提取。
立即学习“前端免费学习笔记（深入）”；
- 别只依赖
doc.body.innerText，输入不含<body>时会返回undefined - 如果输入为空字符串或非法 HTML（如
"<"），parseFromString仍返回有效 Document，但innerText可能为空，建议加空值判断：plainText || '' - 避免在循环里反复 new DOMParser()，实例可复用，但单次解析无需优化
BeautifulSoup 中 .get_text() 的常见陷阱
Python 里用 BeautifulSoup 提取文本，.get_text() 看似简单，但参数组合直接影响结果质量。默认行为会把所有标签间空白压缩成单个空格，丢掉段落换行，对新闻正文或诗歌类内容很不友好。
- 保留段落分隔：传
separator="\n"，再配合strip=True去首尾空行 - 想跳过某些标签（如
script、style）的内容？先用soup.find_all(["script", "style"])遍历调用.decompose()，再调.get_text() - 解析器选错会导致结构错乱：用
"html.parser"最稳妥；"lxml"快但会自动补全缺失标签（如把<p>abc</p><p>def补成<p>def</p>），影响文本位置 - 遇到编码问题（如中文乱码），别硬调
encoding参数，优先让BeautifulSoup自动检测：BeautifulSoup(html_bytes, "html.parser")
为什么不能用正则删 <.*?> 来提取可见文本？
正则表达式匹配 HTML 标签看似快捷，但实际踩坑率极高。它根本无法识别嵌套（<div><span>text</span></div>）、属性含 >（<img src="a>b.jpg">）、自闭合标签（<br/>）、HTML 实体（ ）或注释（<!-- hello -->）。
更危险的是 XSS 风险：正则删标签不处理属性，<img onerror="alert(1)"> 被删后只剩 onerror="alert(1)" 字符串，若后续拼进 innerHTML 就执行了。
- 哪怕只是提取邮箱或 URL 这类固定格式，也应先用 DOM 解析器剥离标签，再对纯文本跑正则
- 服务端无 DOM 环境时，用
html.unescape()+BeautifulSoup是底线方案，绝不用多层.replace()拼凑 - 临时 div 方案（
temp.innerHTML = html; temp.textContent）在浏览器中可行，但要注意 script 标签会被执行——必须确保输入可信
真正难的不是“怎么取文本”，而是判断哪一层文本才符合业务语义：是渲染后用户所见？是 DOM 树上所有文本节点？还是经过样式过滤后的可读内容？选错 API 层级，后面所有清洗逻辑都会偏移。
