每隔几个月，总会冒出一款更快的 HTML 解析器，基准测试满天飞，然后就有人开始说老工具已经过时了。可真到你需要筛出所有“包含某个词”的段落，或者拿到某个匹配节点的父节点时，你又会想起为什么 lxml 还一直开着在另一个标签页里。
lxml 是一个已经有 20 年历史的 libxml2 绑定。它不算“酷”，也不新潮。但在一个非常具体的场景里，它到今天还是没法替代的——任何真正依赖 XPath 的工作——在主流 Python 生态里，确实还没人能正面硬刚。这篇文章会从实战角度聊聊它到底能做什么、它在哪些地方其实一直在偷偷领先，以及哪些默认设置如果不了解，可能会坑到你。
一句话看懂 lxml：它到底是什么
lxml 是 Python 对 C 库 libxml2 和 libxslt 的绑定。它是解析器和序列化器，不是爬虫，也不是浏览器——它把标记语言转成可查询、可编辑的树，再把树重新转回字节流。它提供与 ElementTree 兼容的 API、完整的 XPath 1.0 引擎、XSLT 1.0 和模式校验功能，由 Stefan Behnel 维护，官方标语是 “the most feature-rich and easy-to-use library for processing XML and HTML in the Python language”。
截至 2026-07-14，基于 GitHub 和 PyPI 的快照，它的情况如下：
| 项目 | 值 |
|---|---|
| 仓库 | lxml/lxml |
| Stars | 3,043 |
| Forks | 620 |
| 公开 issue | 16 |
| 许可证 | BSD-3-Clause |
| 创建时间 | 2011-02-11 |
| 最近一次推送 | 2026-07-02 |
| PyPI 稳定版 | 6.1.1（2026-05-18） |
| 内置引擎 | libxml2 2.14.6 + libxslt 1.1.43 |
先说清楚，免得有人觉得我在硬吹：这篇评测里没有什么“秘技”。lxml 已经够老了，这里提到的行为，几乎都能在 lxml 文档、libxml2 更新日志，或者某个 launchpad 讨论串里找到。我没有发现什么独家、未公开的技巧，也不会凭空编一个出来。下面这些内容的价值在于：我把它系统化、量化了，并且把 lxml 本身当成主角来组织，而不是单纯为了显得“新”。
测试设置（以及为什么时间数据是借来的）
这篇评测使用了两类数据，而且来源不同，所以我先把来源说清楚。
能力测试——XPath 行为、两种解析器 API、命名空间、编码、节点生命周期——是在一台机器上重新跑的：macOS arm64、Python 3.14.2、lxml 6.1.1、libxml2 2.14.6。那些 artifacts/raw/*.json 文件里的每个数值，都是脚本运行算出来的，不是手工写进去的。能力测试是确定性的布尔值和枚举值，所以单次运行就足够稳定——机器负载不会改变 //a/@href 到底会不会返回属性字符串。
时间和内存占用数据不属于这次新测试包。 它们原封不动沿用自之前的 selectolax 基准测试包——同一台机器、同一虚拟环境、同样的 lxml 和 libxml2 构建，基准时间截至 2026-07-13——我这次没有重新跑。这样做是有意的。因为如果在跑一批能力脚本的同时再跑时间测试，就很容易出现 CPU 竞争，污染复用的数据；而且那也是重复劳动：在那套测试里，lxml 本来就已经是完整测过的对照库了。复用同一套基准，才能保证前后一致，而不是引入另一套微妙不同的测量结果。所以当你在下面看到毫秒数时，请理解为“同一套测试环境，数据截至 2026-07-13”，而不是“我今天重新计时了”。
结论会带上置信标签：single-observation 表示确定性的能力测试，triple-run 表示复用的时间分布，hypothesis 则表示我在提出一种未单独隔离验证的机制。
XPath：selectolax 和 BeautifulSoup 都没有的核心能力
这就是本文的重点，所以先从这里开始。
我把 lxml 的 xpath() 放进了一个预先注册的 37 项矩阵里测试——每个案例的期望结果都在测试运行前写进源码，因此我不可能事后“按表现给分”。测试覆盖了 10 种轴、9 种谓词写法、10 个内置函数、3 种标量返回类型，以及 5 个故意设置的陷阱案例，使用的是 XPath 2.0 专属语法，而 lxml 的 1.0 引擎按理就应该拒绝它们。
| 类别 | 覆盖项 | 结果 |
|---|---|---|
| 轴（Axes） | child / descendant / parent / ancestor / following-sibling / preceding-sibling / self / attribute / following / preceding | 10/10 通过 |
| 谓词（Predicates） | [1] / last() / position()<n / 属性相等 / 属性存在 / and / or / 嵌套 [.//a] / not() | 9/9 通过 |
| 函数（Functions） | text() / contains() / starts-with() / count() / string-length() / normalize-space() / concat() / substring() / name() / string() | 10/10 通过 |
| 返回类型 | 布尔值 / 数字标量 | 3/3 通过 |
| 陷阱案例 | matches() / 序列 / if-then-else / except / 语法错误 | 5/5 正确拒绝 |
得分是 37/37，而真正值得关注的是“陷阱案例”这一列。matches()、序列表达式、if/then/else 和 except 都是 XPath 2.0 语法，libxml2 的 1.0 引擎不会“部分支持”它们，而是直接抛出 XPathEvalError，拒绝执行，而不是悄悄返回错误的节点集。所以这是一个“先想办法把它搞坏，再仍然满分”的结果，而不是一套专门挑软柿子题目的满分。这里的每个行为都和 lxml XPath 文档描述一致，这正是重点。
我也承认一件事：测试框架一开始确实写错了一个预期，而且这才是你真正可以信任的 37/37。我对 //div[.//a[@href]] 的第一次预期是两个命中，实际只返回了一个。我先以为 lxml 出错了大约 30 秒，后来检查 fixture，发现第二个元素其实是 <footer>，不是 <div>——错的是我的预期，不是引擎。我修正了预期，并在源码注释里保留了这个失误。责任归属就该这样：先怀疑自己的测试，而不是那套 20 年历史的 C 库。
XPath vs CSS：CSS 里根本写不出来的东西
“XPath 更强大”这句话太抽象，所以我把差距量化了一下。lxml 同时提供 .xpath() 和 .cssselect()（后者底层会把 CSS 转成 XPath）。我拿 10 个选择目标测试，看看 CSS 到底能表达几个。
| 目标 | XPath | CSS（cssselect） |
|---|---|---|
按文本内容过滤（contains(text(),"bargain")） | 可以 | 不行，CSS 没有文本谓词 |
从子节点选父节点（//b/parent::p） | 可以 | 不行，没有父选择器 |
返回属性值（//a/@href） | 可以 | 不行，只返回元素 |
返回文本节点（//p/text()） | 可以 | 不行，CSS 不支持文本节点 |
ancestor 轴（//td/ancestor::div） | 可以 | 不行，不能向上导航 |
按子节点数量过滤父节点（//ul[count(li)=4]） | 可以 | 不行，没有计数谓词 |
按文本长度过滤（string-length(text())>5） | 可以 | 不行，没有长度谓词 |
nth-child / last-child / 相邻兄弟 | 可以 | 可以（3 个基础能力） |
10 个目标里，有 7 个 CSS 根本没有对应写法。按文本内容过滤、向上查找父节点和祖先节点、把属性值或裸文本节点作为结果返回、按数量计数的谓词——CSS 都做不到。只有 3 个（nth-child、last-child、相邻兄弟选择）在两边都能实现。这个结果，就是“我到底为什么要用 lxml”的量化答案。selectolax 只能用 CSS，而且根本没有 xpath() 方法，所以那 7 类查询在它那里要么得写成多步 Python 循环，要么根本做不了。如果你的抓取逻辑依赖这些能力，选择其实已经很明确了。
（是的，测试框架在这里又抓到我一次：我原本以为 string-length(text())>5 会返回空集，结果有两个 6 个字符的字符串命中。修正的是预期，不是工具。）
三档严格模式：etree、recover 和 lxml.html
XPath 是你选择 lxml 的原因，而这三档解析严格度，才是你愿意一直留着它的原因。
大多数解析器对损坏输入只有一种处理方式，而 lxml 给你三种，而且它们都足够可预测。我把 6 类畸形标记分别送进去测试，并预先写好了每条路径应该怎么表现。
| 畸形输入 | lxml.etree（严格） | etree + recover=True | lxml.html（宽松） |
|---|---|---|---|
未闭合标签 <root><a>x</root> | 抛错 | 自动修复 | 接受 |
错位嵌套 <b><i></b></i> | 抛错 | 自动修复 | 接受 |
未定义实体 | 抛错 | 自动修复 | 接受 |
裸 &（Tom & Jerry） | 抛错 | 自动修复 | 接受 |
多个根节点 <a>1</a><b>2</b> | 抛错 | 自动修复 | 接受 |
| 规范 XML | 接受 | 接受（0 错误） | 接受 |
布尔属性 <input disabled> | 抛错 | 自动修复 | 接受 |
7 项里有 7 项都和预期一致。lxml.etree 会对这 6 类畸形输入全部抛出 XMLSyntaxError。在同一个解析器里加上 recover=True，它会吞掉错误并重建出可用的树——而且这部分常常被低估——parser.error_log 会逐条列出它吞掉的每个错误。lxml.html 则是全都直接接受，不抱怨。
这里负责判断“抛错 / 恢复 / 接受”的分类器，本身是根据运行时 error_log 的长度来驱动的，而不是硬编码，所以一个在 recover=True 下的规范文档会被正确标成“接受”（空日志），而不是“恢复”。我最初版本的分类器只要 recover=True 就一律标成“恢复”，结果把干净输入误标了；读取真实的 error_log 后问题就解决了。
这在实际使用里意味着什么？如果你面对的是必须严格校验的坏数据源，就用 lxml.etree，让它明确失败。对于脏乱的真实网页 HTML，只要能解析过去就行，那就用 lxml.html。而多数工具做不到的中间状态——“可以宽松处理，但把到底哪里坏了告诉我，我好记录日志”——就用 recover=True，再读取错误日志。selectolax 只有宽松模式，没有严格模式，也没有错误日志。
iterparse：selectolax 完全没有的流式处理能力
这里说的不是速度，而是能力。selectolax 只能一次性吞掉完整字符串——没有增量接口。lxml 的 iterparse 会在元素闭合时逐个吐出节点，配合经典的 fast_iter 模式（一路 elem.clear()，并删除前面的兄弟节点）可以把内存占用维持得非常平，不管文档有多大。
我直接测了内存特征——用 ru_maxrss 看峰值 RSS，每个对象都在一个全新的进程里跑，输入是 30 万个 <record> 元素，总大小约 15 MB。
| 模式 | 峰值 RSS 增量 | 说明 |
|---|---|---|
iterparse + clear（fast_iter） | ~1-2 MB | 处理过程中持续释放；数量再多也基本平坦 |
iterparse 不 clear | ~386 MB | 持有引用；和整文件加载一样重 |
etree.parse（整文件加载，对照） | ~386 MB | 已知会很吃内存；用于验证计量器确实能读出量级差异 |
这种受控模式下的峰值 RSS 增量，大约只有完整加载时 ~386 MB 的 1-2 MB——差不多只占 0.3-0.4% 的量级——而且第一个 record 事件在文件还没读完时就已经触发，所以它真的是增量式处理，不是伪流式。最值得学习的是中间这一行：用同样的 iterparse 循环，但把 clear() 去掉，内存又会涨回 ~386 MB，因为你一直把所有引用都留着。真正的收益来自 clear()，不是 iterparse 本身。整文件加载的对照组明显高出很多，也证明了 RSS 计量器确实能看到这个量级差异，而不是“盲读”。（这个内存测试是我在这次测试包里新跑的——它属于占用测量，和借来的时间数据不同。）
把它翻成现实场景就是：一个装不进内存的多 GB XML 导出，selectolax 根本没法处理。你只能用 lxml 的流式解析器，或者换别的语言。
命名空间：RSS、SVG，以及默认命名空间陷阱
我测了 12 个命名空间案例，覆盖 RSS 中的三套命名空间、带默认命名空间和 xlink 的 SVG，以及默认命名空间 XML。结果全部通过。
lxml 可以从 RSS 源里用 //dc:creator/text() 精确取出 ["Alice", "Bob"]，也能在同一份文档里跨 3 套独立命名空间解析 //atom:link/@href 和 //content:encoded，还能处理 SVG 第二命名空间里的 //s:rect 和 //s:use/@xlink:href，并用 QName 拆解 Clark 记法的 {uri}local 名称，还能通过 nsmap 做内省。这些都是经过维护、文档明确支持的行为，而 selectolax 完全碰不到这一层，因为它只面向 HTML5，不处理任意 XML 命名空间。
不过有一个文档里明确写明、也最值得记住的坑：XPath 根本没有“默认命名空间”这个概念。把 //book 指向一个声明了 xmlns="urn:..." 的文档时，你会得到 0 个命中——XPath 里空前缀是未定义的，正如 lxml 文档所说明的那样。你必须手动绑定一个人为前缀（比如 //c:book，配合 namespaces={"c": "urn:..."}，这样能找到全部 3 个），或者退回到 //*[local-name()='book']（同样能找到 3 个）。这不是 bug，而是 XPath 规范本身就是这么定义的。只是每个人第一次都会被它绊一下。
真实脏页面：11 个真实抓取样本上的还原度
合成测试都很干净，但网页并不干净。我复用了 selectolax 测试包里的 11 个真实抓取页面 fixture（截至 2026-07-10，只读），并把它们交给 lxml.html 处理，以 lxml 作为观察对象。
| Fixture | 大小 | 链接数 | libxml2 恢复错误数 | 严格 XML |
|---|---|---|---|---|
| news_bbc.html | 398 KB | 255 | 4 | ok |
| docs_mdn_array.html | 243 KB | 508 | 0 | 抛错 |
| wiki_scraping.html | 227 KB | 460 | 0 | 抛错 |
| gov_whitehouse.html | 289 KB | 154 | 0 | 抛错 |
| oldstyle_craigslist.html | 561 KB | 351 | 0 | 抛错 |
| forum_reddit.html | 129 KB | 318 | 0 | 抛错 |
| docs_python.html | 80 KB | 341 | 2 | 抛错 |
| ecommerce_books.html | 51 KB | 94 | 0 | 抛错 |
| news_hackernews.html | 35 KB | 229 | 0 | 抛错 |
| ecommerce_webscraper_allinone.html | 16 KB | 35 | 0 | 抛错 |
| spa_quotes_js.html | 6 KB | 5 | 0 | 抛错 |
这 11 个页面都能被 lxml.html 正常解析，而且它们的链接数、标题数、图片数都和 selectolax 测试包里的 lxml 统计值完全一致——交叉校验结果为 true。这个一致性告诉我，复用的数据确实是同一口径，而不是两套不同测量硬贴上了同一个标签。
顺带得到的结论是：严格 XML 解析器在这 11 个页面里有 10 个都会抛错。真实网页几乎都不是规范 XML，这正是 libxml2 的 HTML 恢复模式存在的原因——它就是专门拿来吞这些脏页面的。唯一的例外是 BBC News，它由 Next.js 渲染，足够规范，甚至能撑过严格 XML 解析。并不是所有标着“HTML”的东西都必须走恢复模式。
还有一个很容易搞混的计数差异。对 docs_python.html 来说，//a[@href]（属性存在）计数是 343，而 selectolax 测试包里的 if n.get("href")（值为真）计数是 341。多出来的两个是空的 href="" 链接。这是计数口径差异——属性存在 vs 属性非空——不是 lxml 行为差异；只要把谓词口径对齐，计数就能对上。做抓取时这一点很重要：空 href 算不算，取决于你过滤条件怎么写，不取决于解析器。
看起来像 bug 的深度限制，其实不是
selectolax 测试包里记录过：lxml 在 1,000 层和 5,000 层嵌套的 <div> 标记上会丢掉最深层内容，并把它描述为“lxml 悄悄丢失了最深层内容”。我想搞清楚它的机制，所以把默认解析器和 huge_tree=True 对比了一下。
| 请求深度 | 默认解析器能到达的深度 | huge_tree=True 能到达的深度 |
|---|---|---|
| 300 | 253（其余丢弃） | 299（恢复） |
| 1000 | 253（其余丢弃） | 999（恢复） |
| 5000 | 253（其余丢弃） | 2045（仍然丢弃） |
默认解析器大约会在 253 层处截断，并且悄悄丢掉更深的内容。这不是 bug，而是 libxml2 的 DoS 防护：大约 256 层的嵌套上限，用来阻止恶意文档把栈打爆，这在关于 XML_PARSE_HUGE 的 lxml launchpad 讨论里有说明。把 huge_tree=True 打开后，300 层和 1,000 层都能完整恢复。不过 5,000 层即使开了 huge_tree，也只能到 2,045 层——libxml2 里还有第二道更硬的递归上限，huge_tree 绕不过去。
所以实际行动很明确：如果你解析的是可信来源的深层标记，用 lxml.html.HTMLParser(huge_tree=True)。这次测试包在复用观察之上新增的是机制解释（这是安全上限，不是数据损坏）、修复办法（huge_tree），以及“修复也有到不了的第二道上限”这一点。
DOM 读写、序列化、编码
lxml 是完整的读写树，不是只读提取器，我按项目把编辑能力逐一验证了一遍。8 项 DOM 操作全部通过：SubElement、insert、remove、replace、strip_tags（去标签保留文本）、strip_elements（标签和文本一起去掉）、drop_tree（lxml.html 独有），以及让新手最容易搞混的 text/tail 双槽模型——在 <p>head<b>bold</b>tail</p> 里，p.text 是 "head"，b.text 是 "bold"，b.tail 是 "tail"。
序列化也 5/5 全过：XML 和 HTML 模式下的 tostring（HTML 模式会正确保留空元素不自闭合）、pretty_print、C14N 规范化（method="c14n"，这是另一个 lxml 独有能力），以及一次干净的往返转换。
编码处理是 lxml 悄悄拉开差距的地方。给它非 UTF-8 字节流——比如把 "<p>café éè</p>".encode("latin-1") 喂给 lxml.html.fromstring——它能完整还原出 café éè，没有 U+FFFD 替换字符，也没有字节丢失。这正好对应 selectolax 测试包里把它作为“干净参考”的角色：同样输入在另外两个引擎里都会静默损坏（Lexbor 会产生替换字符，Modest 则直接丢字节）。这里 lxml 背后的 libxml2 编码检测确实更稳。
反过来，lxml 对“你怎么声明编码”又很严格。XML 声明里写 encoding="latin-1" 会抛出 XMLSyntaxError: Unsupported encoding: latin-1，而 IANA 规范写法 encoding="ISO-8859-1" 则可以正常解析并返回 café。libxml2 只接受规范编码名，不接受别名——这个细节在 launchpad #613302 里也有记载。不了解它会很烦；知道之后就只是个小细节。
最后是节点生命周期。我在隔离的子进程里测试了 3 种“悬空句柄”场景（如果真崩了，进程会以非零退出）：树被垃圾回收后继续持有节点、drop_tree() 后读取句柄、以及 remove() 之后继续使用节点。三种都没有段错误——lxml 会保留节点对其树的引用，避免 use-after-free。这个测试里 selectolax 也同样通过了。
速度与内存（借来的，而且我明确承认）
本节所有数据都复用自 selectolax 测试包，时间截至 2026-07-13。这次测试包没有产生任何自己的时间数据，我宁愿多说一遍，也不想让你以为我重新计时了。
| 维度 | lxml 数值 | 解读 |
|---|---|---|
| 纯解析 p50（10 MB） | 77.9 ms | 比 selectolax-Lexbor 快约 33-34% |
| 完整解析 + 提取 p50（1 MB / 10 MB） | 14.18 ms / 172.9 ms | 小体量下与 Lexbor 大致持平 |
| 10 万节点 CSS 吞吐 | 3,002,646 节点/秒 | 三个 C 解析器里最快档 |
| 10 MB RSS 增量 | 128.9 MB | 六个解析器里最省内存，比 BeautifulSoup 约轻 1.7 倍 |
| 冷启动导入 | 14.1 ms | 比 parsel 风格导入快约 2.3 倍 |
纯解析和吞吐数据都很强，而在这六个解析器里，lxml 也是最省内存的。不过线程表现要加一个说明。复用数据里，4 线程墙钟加速只有 1.21x，被标成不确定——但那是共享默认解析器的路径。lxml FAQ 明确指出：只有每个线程使用自己的解析器（或复制默认解析器）时，解析过程中才会释放 GIL；共享解析器会把访问串行化。我已经结构化验证了正确使用所需的 API 表面（XMLParser.copy() 存在，get/set_default_parser 存在，XPathEvaluator 也带内部锁），但我没有测“每线程一个解析器”的加速，这会是新的时间测量，而这次测试包不产出那类数据。所以请把“1.21x”理解为“在天真的共享路径下的结果”，而不是 lxml 的线程上限。
另外，这些数据都有一个星号：它们都是单平台数据，macOS arm64。lxml 的纯解析速度优于 Lexbor 这件事，与业内通常认知“Lexbor 后端通常更快”是有冲突的，所以在任何人把它当成定论之前，都值得在 Linux x86_64 上再核一次。
许可证：一个很无聊但很重要的胜利
lxml 使用 BSD-3-Clause 许可证，随包捆绑的 C 库 libxml2 和 libxslt 都是 MIT 许可证。这是一条完全宽松、没有任何 copyleft 的链条；只要你要再分发，这点就非常重要。对比来看，selectolax 的 wheel 包含 LGPL-2.1 的 Modest 和 Apache-2.0 的 Lexbor，所以如果你要把它塞进闭源产品，lxml 的法律路径更干净。
安装体验上也有实际好处：lxml 发布了预编译 wheel，静态链接 libxml2 和 libxslt，所以 pip install lxml 一般不需要系统级 libxml2，也不需要你机器上有编译器——这和从源码构建它完全是两种体验。
lxml 适合什么场景——以及 AI 提取层会接管什么
这里需要把边界说清楚，因为这很容易被混淆。lxml 是一个解析库。它给你的是一棵树和一个极强的查询引擎，而围绕这棵树的工作仍然要你自己负责：抓页面、渲染 JavaScript、绕过反爬、防机器策略、编写并维护 XPath，以及整理输出结构。那是另一层，和托管式提取服务不是竞争关系，更像邻居。
对于那些不想自己维护“抓取-渲染-选择器-维护”整条链路的开发者来说，像 Thunderbit 这样的产品就属于更上层的方案——而对本文读者来说，它更像 API、MCP Server 和 CLI，而不是浏览器扩展。 Thunderbit Open API 提供 POST /distill，把页面转成干净的 Markdown；也提供 POST /extract，基于 JSON Schema 提取结构化数据，并支持 renderMode 切换和批量任务处理。相同引擎还可通过 MCP Server（thunderbit_suggest_fields、thunderbit_distill、thunderbit_extract）供 agent 和编程助手使用，也可以通过 CLI 直接在终端里用 npx @thunderbit/thunderbit-cli 运行。它开箱即用地处理 JS 渲染、反爬和 CAPTCHA，并返回符合 schema 的 JSON——这是一层高于解析的能力，不是替代解析本身。
这件事的分工其实很简单：如果你自己掌控整个管线，并且想对一棵你理解的树做精准 XPath 控制，就选 lxml。如果你不想维护选择器和渲染逻辑，那就用 AI 提取 API。很多真实系统会同时使用两者：lxml 负责你能掌控的结构化 feed，提取服务负责那些混乱、长尾、你不想碰的页面。
这篇评测没有测什么
这是一篇阶段性评测，不是最终判卷，所以也说明一下它没有覆盖什么。
所有时间和内存数据都来自复用、单平台（macOS arm64，Python 3.14），并继承了那套测试包的限制——“lxml 在纯解析上更快”这个结果与常见共识相反，仍然需要在 Linux x86_64 上复核。每线程一个解析器的线程加速没有测（那需要新的计时）。我测了 30 万条记录的 iterparse 内存，但没有测 GB 级真实 XML，也没有测 HTML 与 XML 的 iterparse 对比，更没有做多小时长时间稳定运行。lxml 的 XSLT 1.0、RelaxNG / XMLSchema / DTD 校验，以及 EXSLT 扩展，这里都完全没测——这些是很大的能力面，但已经超出解析与选择核心。虽然我观察到了 2,045 层的第二道深度上限，但没有进一步精确定位 libxml2 的递归常量。这里只测了稳定版 6.1.1，没有测 7.0.0 alpha。Windows、源码构建，以及 free-threaded 的 3.14t 构建也都没测。并且在 XPath 本身这块，我只覆盖了内置函数，没有测 XPath 变量、自定义 Python 扩展函数，或者预编译的 etree.XPath 对象复用。
结论
lxml 不是那种“又快又新”的工具，而这恰恰是它的优势。它是一个已经有二十年历史的 libxml2 绑定，带着一个主流 Python 生态里没有谁能完全替代的 XPath 1.0 引擎，拥有三档可预测的解析严格度，中间还带错误日志；它有真正的流式解析器，能处理放不进内存的文档；它能正确处理多命名空间和编码；而且许可证还是彻底宽松的。那几个尖锐边角——大约 253 层的深度上限，以及共享解析器下的线程表现——都已经被文档化、可配置，而且现在也解释清楚了。
如果你自己掌控抓取管线，并且重度依赖 XPath，那 lxml 依然是你该优先拿起的解析器。如果你不想维护选择器和渲染逻辑，那就把这件事交给像 Thunderbit API、MCP 和 CLI 这样的 AI 提取层——这是清晰的职责分工，不是正面竞争。无论你选哪边，都请把这些数字当成阶段性结果，在自己的平台上重新验证性能，再写进设计文档。
试用 Thunderbit 进行网页数据提取 Get Started Free
常见问题
lxml 是网页爬虫吗？
不是。lxml 是解析器和序列化器——它是 libxml2/libxslt 的 Python 绑定，把标记语言转成可编辑、可查询的树。它不会抓取页面、不会渲染 JavaScript，也不会处理反爬策略；请求层需要你自己提供（比如用 requests、httpx、无头浏览器，或者抓取服务），再把字节流交给 lxml。
什么时候该用 lxml，而不是 BeautifulSoup 或 selectolax？ 当你需要 XPath 时，就该用 lxml。BeautifulSoup 虽然可以把 lxml 当后端解析器，但它本身不提供原生 XPath；selectolax 只支持 CSS，并且在自己的狭窄场景里更快。如果你的选择逻辑需要按文本内容过滤、向上找父节点或祖先节点、提取属性/文本节点，或者按数量计数做谓词，lxml 的 XPath 引擎是主流 Python 里少数能直接表达这些需求的方案。
为什么 lxml 会悄悄丢掉深层嵌套内容？
它的默认解析器会把嵌套深度限制在大约 253 层——这是 libxml2 防御恶意文档的 DoS 安全措施，不是 bug。把 huge_tree=True 打开（例如 lxml.html.HTMLParser(huge_tree=True)），300 层和 1,000 层都可以恢复。但要注意，还有一道更硬的递归上限，大约在 2,045 层左右，huge_tree 也绕不过去。
lxml 在多线程解析时会释放 GIL 吗？ 只有在条件正确时才会。lxml FAQ 说明：当每个线程使用自己的解析器，或者使用复制出来的默认解析器时，解析过程中才会释放 GIL；如果共享同一个解析器，访问会被串行化。这里复用的 4 线程加速 1.21x 反映的是“共享解析器”的天真路径，不是每线程独立解析器的上限——后者这次并未测量。
lxml 到 2026 年还在维护吗？ 是的。稳定版 6.1.1 于 2026-05-18 发布，仓库最近一次推送是 2026-07-02，而且 7.0.0 alpha 也在推进中。GitHub 大约有 3,000 个星标，底层的 libxml2 也仍然活跃维护，所以它现在依然是一个在用、受支持的现代库，而不是“古董”。
