Selectolax比BS4快得多，因其底层用C编写的Lexbor引擎直接解析HTML、跳过DOM树构建中间层；而BS4依赖Python实现的html.parser（慢）或启动重/内存高的lxml，实测解析10MB文件快8–12倍（vs html.parser）或1.5–3倍（vs lxml）。
为什么Selectolax比BS4快得多？ Selectolax底层用C写的libhtml5parser，直接跳过DOM树构建的中间层，解析完就给节点对象；BS4默认用Python写的html.parser，或者依赖lxml（虽快但启动重、内存高）。实测10MB HTML文件，Selectolax通常比BS4 + html.parser快8–12倍，比BS4 + lxml也快1.5–3倍——尤其在大量嵌套标签或乱码HTML下优势更明显。
关键不是“语法像不像BS4”，而是它压根不模拟DOM标准：没有find_all()那种递归搜索，所有查找都是单次前序遍历，不缓存父链，也不自动修正标签闭合。这意味着你得自己处理“找不到就None”和“文本节点可能被拆成多个”的情况。
Selectolax基础用法：怎么加载和查元素？
安装只要pip install selectolax，没额外依赖。加载HTML和查元素非常轻量：
from selectolax.parser import HTMLParser
<p>html = "<div class='item'><p>Hello</p></div>"
tree = HTMLParser(html)</p><h1>查第一个匹配节点（返回Node对象，不是列表）</h1><p>node = tree.css_first("div.item")
if node:
print(node.text()) # "Hello"
print(node.attributes.get("class")) # "item"</p><h1>查所有匹配节点（返回NodeList，支持len/for，但不支持索引）</h1><p>for p in tree.css("p"):
print(p.text())
注意三点：
-
css()和css_first()是主力方法，不支持BS4里的find()/find_all()别名 - 返回的
Node对象没有.parent或.next_sibling这种导航属性——要往上找得靠node.parent，但它只返回一个父节点，且可能为None -
node.text()默认会合并空白、去换行；要保留原始文本用node.text(strip=False)
常见踩坑：乱码、自闭合标签、动态内容怎么处理？
Selectolax默认按UTF-8解析，遇到<meta charset="gb2312">这类声明完全无视——它不读meta，也不重编码。如果源HTML是GBK，必须提前解码：
立即学习“Python免费学习笔记（深入）”；
html_bytes = b"<div>\xc4\xe3\xba\xc3</div>" # GBK编码的"你好"
html_str = html_bytes.decode("gbk")
tree = HTMLParser(html_str)
自闭合标签如<img>、<br>没问题，但<script>和<style>的内容默认会被解析为文本节点（不像BS4可设parse_only）。如果只想提取结构，建议先用正则粗略剔除script/style块，再喂给Selectolax。
它不执行JS，也不等DOMContentLoaded——纯静态解析。想处理Ajax加载的内容，得先用Playwright或Requests-HTML拿到完整HTML，再交给Selectolax。
什么时候不该换？性能之外的关键限制
Selectolax不适合以下场景：
- 需要频繁向上/横向遍历（比如“找某个span的上一个兄弟div”），因为
Node的parent和next属性不稳定，且不保证存在 - 要修改HTML结构再输出（它不提供
replace_with()或insert_after()） - 依赖CSS选择器里的伪类（
:nth-child、:has()全不支持） - 需要XPath（Selectolax只支持CSS选择器）
如果你的流程是“下载→解析→提字段→入库”，且字段路径固定、HTML质量尚可，Selectolax几乎零学习成本就能提速；但一旦涉及复杂导航或容错修复，BS4+lxml仍是更稳的选择。最常被忽略的一点：Selectolax的NodeList不能切片（nodes[1:3]报错），得转成list再操作。
