正则匹配以特定字符串结尾的html文本需用re.findall(r">(1*?)结尾词(?=|$)", html_str, re.dotall)——捕获标签内容中紧邻结尾词的纯文本，避开标签干扰。& ↩
用正则匹配以特定字符串结尾的文本片段
直接用 re.findall(r".*?结尾词$", html_str, re.DOTALL) 会失败——因为 HTML 中换行、空格、标签混杂，.*? 默认不跨行，且无法跳过中间标签。真正能用的模式是：re.findall(r">([^，它靠“<code>>”和“”锚定标签边界，捕获两个标签之间、以目标词结尾的纯文本。
常见错误现象：匹配结果为空或漏掉换行后的文本；或把 <span>abc</span>结尾词 这类结构误判为“结尾”，其实中间有闭合标签。
- 必须加
re.DOTALL，否则.不匹配换行符 - 结尾词若含正则元字符（如
.、?、(），要用re.escape(ending)包裹 - 如果结尾词前后可能有空白或换行，用
\s*替代硬空格，但别放太宽，否则会吞掉相邻文本
用 BeautifulSoup 定位并过滤元素文本
当“指定结尾”对应的是某个 HTML 元素的可见文本（比如所有 <p></p> 标签中以“…详情”结尾的内容），BeautifulSoup 比正则更可靠。核心不是搜字符串，而是先找元素，再检查其 .get_text() 是否满足结尾条件。
使用场景：目标文本被包裹在语义明确的标签里（如 <div class="desc">），且结尾规律稳定（如统一带“[已归档]”“（失效）”）。<ul>
<li>用 <code>soup.find_all("p") 获取所有段落，再逐个判断 elem.get_text(strip=True).endswith("（失效）")
elem.text，它可能包含隐藏标签内的文本；.get_text() 更干净separator="\n"，否则多段落会挤成一行用 XPath 提取父元素内以某词结尾的直接文本节点
当目标文本是父元素的“裸文本子节点”（即不在任何子标签内），且恰好以某字符串结尾，lxml 的 XPath 可精准定位：//div[@class="item"]/text()[contains(., "更新于")][substring(., string-length(.) - string-length("更新于") + 1) = "更新于"]。这比用 Python 后过滤更高效，尤其处理大文档时。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
容易踩的坑：XPath 的 text() 只返回直接子文本节点，不会递归；若目标文本被 <br> 或注释隔开，会被切分成多个节点，单个节点长度可能不足。
- 优先用
contains(., "关键词")快速筛选，再用substring()做精确结尾校验 - 不要依赖
last()—— 文本节点顺序受 DOM 解析影响，不一定对应视觉顺序 - 若父元素内有多个文本节点，且只想要最后一个以某词结尾的，得用 Python 二次遍历
浏览器环境里用 DOM + textContent 做轻量级结尾提取
在前端 JS 环境中，最简方式不是解析整页，而是创建临时容器，注入 HTML，再遍历所有文本节点检查结尾：temp.innerHTML = htmlStr; Array.from(temp.childNodes).filter(n => n.nodeType === 3).some(n => n.textContent.trim().endsWith("PDF"))。
性能影响明显：对超长 HTML 字符串，反复创建/销毁 DOM 节点比纯字符串操作慢 5–10 倍；但胜在兼容性好、不依赖外部库、能正确解码 HTML 实体（如 ）。
-
nodeType === 3是文本节点的固定值，别写成==或漏掉类型判断 -
textContent比innerText更可靠——后者受 CSSdisplay:none影响，会跳过隐藏文本 - 如果只需要判断“是否存在”，用
some()；若要提取全部匹配项，改用filter()+map(n => n.textContent.trim())
提取“以某字符串结尾”的文本，本质是定位文本所在上下文再做后缀判断。正则快但易碎，DOM 方法稳但重，XPath 精准但学习成本高——选哪个，取决于你手上的 HTML 是否规范、是否需要保留结构语义、以及运行环境是否可控。
