应放弃递归遍历改用 queryselectorall：它一行跨层级精准选取、返回静态 nodelist、底层调用原生解析器，性能远超手动遍历；兼容 ie8+ 需避开伪类。
直接用 querySelectorAll() 配合合理选择器，比手动遍历 DOM 树快得多；对本地 HTML 字符串或文件，优先选 lxml 而非 BeautifulSoup（尤其当结构清晰、需高频 XPath 查询时）。
什么时候该放弃递归遍历，改用 querySelectorAll
浏览器环境里硬写 childNodes + nextSibling 循环查子节点，既慢又容易漏掉文本节点或注释节点。现代 DOM API 已经把常见查找逻辑封装好了：
-
querySelectorAll("article > h2, .summary p")一行就能跨层级取多个目标，不用管嵌套深度 - 它返回的是静态
NodeList，不会因后续 DOM 变更而失效，比getElementsByClassName更可控 - 若需兼容 IE8+，避免使用伪类（如
:not()、:nth-child()），否则返回空数组但不报错 - 性能上，
querySelectorAll在 Chrome/Firefox 中底层调用的是原生 C++ 解析器，比 JS 层遍历快一个数量级
解析本地 HTML 字符串：lxml.fromstring 比 BeautifulSoup 快在哪
如果你手上有 HTML 字符串（比如从文件读取、API 返回或模板渲染结果），且文档结构基本规范，lxml 的 fromstring() 是更轻量的选择：
-
lxml是 C 实现，解析速度通常是BeautifulSoup(html, "html.parser")的 3–5 倍，BeautifulSoup(html, "lxml")虽快但多了一层包装开销 -
doc.xpath("//div[@class='item']//span/text()")比soup.select("div.item span")更精确控制路径和文本提取时机 - 不自动修复缺失闭合标签（如
<br>
不补成<br>
），这意味着结果更接近原始结构，调试时不易迷惑 - 若 HTML 真的很烂（比如大量未闭合的
<p></p>、混用大小写标签），lxml可能抛LxmlError，而BeautifulSoup会默默容错——这时候得先判断你是否需要“忠实还原”还是“尽力修复”
避免在循环中反复调用 find() 或 select()
这是 BeautifulSoup 用户最容易拖慢性能的地方：每次 find() 都会重新遍历整棵子树。
- 错误写法：
for item in soup.find_all("li"): title = item.find("h3").text; desc = item.find("p").text—— 每次find都从item开始全量扫描 - 正确写法：
for item in soup.find_all("li"): title = item.select_one("h3").text if item.select_one("h3") else ""，或更优：提前用select("li h3, li p")一次性提取所有目标节点再分组 - 如果必须用
find()，确保父节点已足够窄（比如先soup.find("main")再在其上调用find_all），避免每次都从document根开始 -
select()底层走 CSS 解析器，比find()多一层编译成本，但批量查询时均摊下来反而更快
真正复杂的 HTML（比如含大量 script 标签、内联样式、动态插入节点）没法靠单个 API 走捷径；此时得先做减法——用 unwrap() 或 decompose() 干掉干扰节点，再查。别指望一个解析器能同时兼顾速度、容错和语义理解。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
