2014年夏天我接手了一个至今想起来都头皮发麻的活儿抓某个垂直网站的产品库估算下来两百万个页面。HTTP请求用requests扛得住页面解析却成了头号瓶颈——当时主力解析方案是正则和字符串切片几万个页面跑下来不仅匹配规则漏洞百出性能也完全上不去。后来换成lxml库解析速度提升接近一个数量级踩过的坑也让我把XPath、ElementTree这些东西彻底吃透了。这篇东西是python爬虫工程师成长之路系列的第六篇第二弹主要讲非结构化数据里最硬核的解析工具——lxml。网上讲lxml的教程不少但多数停留在这样写能跑的层面很少讲为什么慢、为什么解析不到、为什么明明XPath对了一运行就报错。这篇文章适合已经会写基础爬虫、但被页面解析搞到怀疑人生的朋友也适合想搞懂ElementTree和XPath本质的人。1. lxml是什么以及为什么爬虫工程师早晚要用它非结构化数据这个概念听起来唬人本质上就是HTML网页这类没有固定表结构、字段位置靠标签语义表达的数据。爬虫抓回来的Response对象是文本文本变成可查询的节点树中间需要解析器。1.1 正则能做到的事为什么还要多学一个库早期爬虫教程特别喜欢教正则因为正则能解决看起来很简单的文本提取。比如抓标题一个title(.*?)/title就完事了。但如果页面里嵌套了同名的title标签、属性里夹着非法字符、标签跨行书写正则的脆弱性就凸显出来了。更重要的是正则完全不理解HTML的层级关系。你要抓的是商品列表里第一项的标题如果页面结构是同类型节点不断嵌套正则写起来会非常痛苦而且规则稍微变化就崩。lxml把HTML变成一棵树树的每个节点都有路径查询节点本质上是沿着树找路这跟正则在字符串里搜索匹配是两种完全不同的抽象层次。1.2 HTML文档在lxml里的样子我习惯把解析后的文档想象成一棵家族树根节点之下有head和body两个大分支body里又套着div、ul、li这些节点每个节点还可以拥有属性。lxml的核心数据模型叫ElementTree它把文档拆成一个个Element对象。每个Element有自己的标签名、属性字典、文本内容还能通过父子关系组成递归结构。from lxml import etree html_doc html body div classcontainer ul idlist li classitem苹果/li li classitem香蕉/li /ul /div /body /html tree etree.HTML(html_doc) root tree.xpath(//ul[idlist])[0] print(root.tag) # ul print(root.attrib) # {id: list} print(root[0].text) # 苹果一旦文档被解析成树我们后续做XPath定位、节点遍历、文本提取全部围绕这棵树进行。lxml在C层面实现了libxml2和libxslt所以解析效率极快几十MB的HTML也能在秒级完成。1.3 对比其他解析方案lxml的定位在哪Python生态里常见的解析方案有标准库html.parser第三方BeautifulSoup4以及lxml。它们的定位差异很大html.parser仅做基础解析API原始不推荐在真实爬虫项目里直接用。BeautifulSoup4API友好容错极强文档破碎的页面也能解析适合快速开发和临时脚本。lxml解析速度快XPath能力突出适合大规模采集和精细定位。我实际做性能对比的时候同样一个几千行的HTML文件lxml的解析耗时大约是BeautifulSoup的六分之一到八分之一。当数据量上来以后这个差距是决定性的。但如果页面是那种标签错到离谱的野生站点lxml容错不如BeautifulSoup这时候我会选择先用lxml试不行再降级到BeautifulSoup这个策略放在第4节详细讲。2. 从HTML字符串到可查询的树两种构造方式的选择lxml里最常用的构造入口有两个etree.HTML()和etree.fromstring()。很多人不区分这两个结果遇到编码报错或者解析结果异常时根本不知道问题出在哪。2.1 etree.HTML对破碎文档的容忍度etree.HTML()底层走的是libxml2的HTML解析器专门为真实互联网页面设计。真实页面有多脏标签不闭合、属性不带引号、JavaScript片段混在HTML里、甚至标签名大写它都能吞下去。from lxml import etree broken_html html body div classtest p第一段 p第二段 /div tree etree.HTML(broken_html) result tree.xpath(//div[classtest]//p/text()) print(result) # 输出: [第一段, 第二段]这个例子里我没有写/p闭合标签etree.HTML()照样能正确还原层级关系。这种容错能力是爬虫刚需因为反爬策略里有一个很常见的手段就是故意不按标准写页面结构。2.2 fromstring与严格XML模式的差异etree.fromstring()默认走XML解析器HTML文档直接喂进去大概率会报XMLSyntaxError因为XML对标签闭合、属性引号、根节点都有严格约束。from lxml import etree xml_doc root item id1数据一/item item id2数据二/item /root root etree.fromstring(xml_doc) items root.xpath(//item) for item in items: print(item.get(id), item.text)如果目标数据本身就是XML、RSS、SVG这类规范结构fromstring是首选。如果目标是网页应使用etree.HTML。有个细节值得注意etree.HTML解析出来的文本如果原页面有中文字符要确保传入的是正确解码后的Unicode字符串或者源内容是字节串且声明了正确的charset。2.3 编码问题中文页面乱码的根源lxml最常见的坑是编码。网页HTTP响应头里声明的charset和页面meta标签里声明的charset经常不一致。requests库会用响应头推测编码一旦推测错误汉字就变成乱码解析器的语义判断不会受影响但提取出来的文本没法用。我的处理方式是先用requests拿到二进制内容从响应头取charset再从页面meta里取charset优先采用后者实在拿不准就通过页面字节分布做启发式判定或者直接试解码。lxml里还有个etree.HTMLParser(encoding...)参数可以显式指定编码能避免很多隐性错误。from lxml import etree parser etree.HTMLParser(encodingutf-8) tree etree.HTML(response.content, parserparser)3. XPath定位的完整逻辑从入门语法到复杂业务场景XPath是lxml的灵魂。很多用户用lxml只用xpath但写XPath的人经常卡在语法对但取不到值“取到空列表“路径随着页面改版就失效”这些问题上。这一节我不讲语法手册而是把我实际排查问题的思路完整还原一遍。3.1 XPath把找元素变成了沿树寻址如果把HTML树想成一座城市的街道网络XPath就是一套寻址规则/表示从根节点开始走//表示在整个子树里搜索相当于不看路径只按门牌号找人.表示当前节点..表示父节点表示取属性。# 取所有class为item的节点 nodes tree.xpath(//*[classitem]) # 取id为list的ul节点下的所有li list_items tree.xpath(//ul[idlist]/li) # 取第一个li的文本 first_text tree.xpath(//ul[idlist]/li[1]/text())这里有个新手极易踩的坑XPath下标从1开始而不是Python的从0开始。我见过不止一个同事用li[0]去取第一个节点结果返回空列表排查半天才发现下标写错。3.2 为什么用浏览器复制的XPath经常跑不通很多入门教程教大家用浏览器开发者工具右键复制XPath。复制出来的路径通常是这样的/html/body/div[3]/div/div[2]/div[1]/div[2]/div/1/a这种路径对元素层级极其敏感页面只要多一个包裹的div整条路径就作废了。而且动态网页的内容是JavaScript渲染出来的这种路径往往非常长语义也不明确。解决思路是用自己的语义去写相对路径抓住节点的稳定特征比如id、class、data-xxx属性。稳定的特征是你给XPath打的锚点锚点选得好页面小改版也不至于全崩。3.3 一个真实案例翻页列表的XPath设计假设一个电商列表页结构是div classproduct-list div classproduct>product_nodes tree.xpath(//div[contains(class,product)][data-id]) for node in product_nodes: title node.xpath(.//a[classtitle]/text()) price node.xpath(.//span[classprice]/text()) print(title, price)逻辑核心是先锁定包含product类的所有商品节点再在每个节点内部继续相对查找。这样即使外层结构变化只要商品块的特征还在代码就还能用。我在实际项目里经常把定位商品节点和提取字段分开写定位部分一旦失效日志能直接暴露出来而不是让整个采集流程假装成功。3.4 谓词与条件组合处理动态页面中兄弟姐妹差异XPath的谓词[...]提供了丰富的条件能力比如last()取最后一个节点position()取节点位置not()排除某些节点starts-with()、contains()做属性内容的模糊匹配。# 选择最后一个商品 last_item tree.xpath((//div[classproduct])[last()]) # 排除隐藏商品 visible_items tree.xpath(//div[classproduct][not(contains(style,display:none))])这类写法在处理运营故意隐藏但仍在DOM里的节点时非常有用。很多反爬页面会把隐藏商品、隐藏属性、隐藏链接放在DOM里用XPath谓词过滤比拿回来再在Python里多做一层判断高效很多。4. 性能优化和容错细节大规模采集实战才是试金石lxml性能好是公认的但性能好不等于不需要优化。面对百万级页面时解析器的调用方式、XPath编译策略、节点树复用方式都会影响最终采集吞吐量。4.1 XPath编译与复用每次调用tree.xpath(expression)lxml内部都要做一次表达式编译。如果你在一个循环里对成千上万次页面执行同样的提取表达式重复编译的开销积累起来并不小。正确做法是用etree.XPath()预先编译表达式from lxml import etree expr etree.XPath(//div[classproduct]//a[classtitle]/text()) tree1 etree.HTML(html_1) tree2 etree.HTML(html_2) titles_1 expr(tree1) titles_2 expr(tree2)实测下来XPath表达式预编译对单次页面提升不明显但批量采集时整体能省下10%到20%的解析时间。这个比例在大量页面面前非常可观。4.2 只在必要时使用完整DOMlxml能够解析完整HTML但如果页面本身包含大量与目标无关的节点解析完再查找内存和CPU都会浪费。如果页面结构允许使用lxml的etree.XMLParser(recoverTrue)处理XML片段或者配合remove_blank_text等参数简化树结构也是一种优化手段。不过这个方案不适合所有场景因为HTML结构碎片化后某些XPath路径会变得不可用。我的策略是先用完整解析保证正确性在采集量确实大到内存不够时再考虑精简解析逻辑。不要盲目优化先分析瓶颈。4.3 页面解析失败时的降级预案lxml对有些畸形HTML的处理结果不符合预期比如页面中混着严重不合法的标签嵌套或者编码声明与实际编码严重不一致。遇到这种情况我的降级方案分两步第一步尝试修复编码后重新解析第二步降级到BeautifulSoup的html.parser解析器。from bs4 import BeautifulSoup # lxml解析异常时 soup BeautifulSoup(response.text, html.parser) title soup.select_one(h1.product-title).get_text(stripTrue)BeautifulSoup内部有自己的一套树构建逻辑对某些极端错乱页面能给出比lxml更合理的结果。生产环境里这种解析器双保险非常实用尤其是在采集一批来源混杂、维护质量参差不齐的站点时。4.4 并发采集时怎么共享解析器多线程爬虫里etree.XPath对象可以安全地跨线程复用吗我的经验是对于CPython预编译的XPath对象在不同线程间调用只要不共享同一个ElementTree实例基本没有大问题但共享同一个元素树对象做并发修改则可能出问题。保险做法是每个线程持有自己的XPath表达式和元素树不要全局共享一棵树。import threading from lxml import etree expr_cache threading.local() def get_expr(path): if not hasattr(expr_cache, expr): expr_cache.expr etree.XPath(path) return expr_cache.expr用线程局部变量缓存编译后的XPath既能享受编译复用又不会在线程间产生交叉访问的隐患。这个细节在真正的高并发采集框架里价值很大。5. 五个让我记忆深刻的小坑与排查过程这一节是我实际项目中最常遇见的错误逐个还原排查过程很多坑看起来小但排查成本极高。5.1 为什么xpath返回空列表却没有任何报错XPath定位不到节点时lxml不会抛异常而是安静地返回空列表。这就导致很多人在页面改版后采集结果突然变空但日志没有Error程序依然正常跑。排查顺序我建议这样先用len(tree.xpath(...))确认找到的节点数再打印页面片段确认结构然后检查页面是否为动态渲染、抓到的内容里是否存在对应节点。product_nodes tree.xpath(//div[classproduct]) if not product_nodes: # 把页面片段和当前URL记下来便于定位问题 print(未找到商品节点页面长度:, len(html), url:, url)5.2 text()和xpath-string值之间到底差在哪一个非常经典的困惑//a/text()返回的是当前节点直接文本子节点列表而string(//a)返回的是整个节点内全部文本内容拼起来的值。这两种结果往往不一样。html_doc a href/p/1.html 无线鼠标 span classtag热卖/span /a tree etree.HTML(html_doc) # text() 只获取直接子文本 print(tree.xpath(//a/text())) # [\n 无线鼠标\n ] # string() 获取整个a节点的字符串值 print(tree.xpath(string(//a))) # 无线鼠标热卖如果你的目标字段跨子节点夹着文本使用直接text()会漏数据必须用string()配合节点上下文提取。我通常在提取标题时优先string()因为标题里出现span标签做修饰实在太常见了。5.3 相对XPath前面的点丢了结果全乱在节点内部做二次提取很容易写成不带点的绝对路径for node in product_nodes: title node.xpath(//a[classtitle]/text()) # 错误示范注意这里XPath字符串以//开头它搜索的范围是整棵文档树而不是当前的node。结果可能就是每次都取到全局第一个商品的标题而不是当前商品的标题。正确写法是在//前面加个点title node.xpath(.//a[classtitle]/text())这一点只差一个字符但逻辑完全不同。我排查过不少为什么所有商品标题都一样的bug八成都是这个原因。5.4 属性值带空格和换行contains也用得不灵页面里常见的class是混合式命名比如classproduct-item product-main active想精确匹配classproduct-item是匹配不到的。很多人因此换成contains(class,product)但product这个词可能出现在其他无关节点的class里误匹配率升高。更稳的方案是用CSS类选择器语义转换过来的技巧或者用多个条件组合# 同时匹配多个条件 tree.xpath(//div[contains(class,product) and contains(class,main)])如果属性值里有换行符或大量空白XPath字符串比较也会失败我一般先对属性值做normalize-space()例如tree.xpath(//div[normalize-space(class)product-list])5.5 动态加载内容在lxml里永远找不到现在多数网站的列表详情内容由JavaScript异步加载requests拿到的HTML里根本不存在目标节点。lxml再强大也不会帮你执行JS。这个坑的解决方案不在于lxml而在于数据获取阶段。常见思路有两个一个是用Selenium、Playwright等自动化工具体渲染后再喂给lxml另一个是抓包分析Ajax接口直接采集接口返回的JSON然后在Python里用json模块解析。我的建议是优先抓接口性能差距是数量级的。lxml负责的应该是静态页面服务端渲染页面这部分动态内容尽量交给接口解析。把合适的工作交给合适的工具这是爬虫架构设计里的基本素养。6. 完整实战用lxml构建一个可复用的商品解析器理论说了一大堆最后拼一个真实可用的解析器。这个解析器针对的页面结构常见于中小型电商站点结构大致如下div classproduct-grid div classproduct-card>from lxml import etree class ProductParser: def __init__(self, html_text): self.tree etree.HTML(html_text) def get_product_nodes(self): return self.tree.xpath(//div[contains(class,product-card)][data-id]) def parse_product(self, node): return { product_id: node.get(data-id), name: node.xpath(string(.//h2[contains(class,product-name)])).strip(), desc: node.xpath(string(.//p[classproduct-desc])).strip(), price: node.xpath(string(.//span[classprice-current])).strip(), original_price: node.xpath(string(.//del[classprice-original])).strip(), cart_url: node.xpath(.//a[contains(href,/cart/add)]/href), } def parse(self): products [] for node in self.get_product_nodes(): products.append(self.parse_product(node)) return products这里有个细节string()方法返回的可能是None如果节点不存在的话。所以我在字段输出前统一做了.strip()处理但如果string()结果是None直接调用.strip()会抛异常实际项目里我会套一层安全处理。def safe_text(value): return value.strip() if value and isinstance(value, str) else 6.2 解析器接入多页采集解析器只负责单页解析批量采集时在外部循环里调用即可。我用生产者消费者模式一组线程抓取页面一组线程解析存储。解析线程从队列里拿HTML文本交给ProductParser处理。import queue import threading parse_queue queue.Queue(maxsize100) results [] def parser_worker(): while True: html parse_queue.get() if html is None: break parser ProductParser(html) products parser.parse() results.extend(products) parse_queue.task_done()我把XPath表达式提到了类属性里避免每次解析都重新编译一遍class ProductParser: PRODUCT_XPATH //div[contains(class,product-card)][data-id] NAME_XPATH string(.//h2[contains(class,product-name)]) def get_product_nodes(self): return self.tree.xpath(self.PRODUCT_XPATH)6.3 把这个解析器从单页扩展成框架单一解析器解决的是一个页面但真实采集场景里一个站点往往有多种页面列表页、详情页、搜索页、分页接口。这些页面结构不同但解析思路一致。我会把通用逻辑抽象成一个BaseParser子类覆写节点定位和字段提取方法class BaseParser: def __init__(self, html_text): self.tree etree.HTML(html_text) def get_nodes(self): raise NotImplementedError def parse_node(self, node): raise NotImplementedError def parse(self): return [self.parse_node(n) for n in self.get_nodes()]每个站点的解析规则变成一个子类后续添加新网站时复制一个子类改XPath即可。这种模式我用了好几年维护成本比裸写解析脚本低很多。6.4 采集结果的校验策略解析器输出结果后不能直接入库一定要做字段完整性检查。我在生产脚本里设定了指标商品ID、名称、价格三个关键字段必须有值缺失率超过5%就触发告警。def validate_products(products): required [product_id, name, price] valid_count 0 for product in products: if all(product.get(field) for field in required): valid_count 1 rate valid_count / len(products) if products else 0 if rate 0.95: raise ValueError(f商品数据完整率过低: {rate:.2%})这个校验让我在页面改版后第一时间发现问题而不是等数据入库、报表跑完才发现异常。7. 爬虫工程师如何系统化掌握lxml一个学习路径建议看到这里你可能已经能处理大多数解析场景了。但会写XPath和系统化掌握lxml之间仍有距离。我建议按下面这个路径进阶。7.1 从文档树思维开始不要把lxml当字符串处理的替代品。先把文档树节点属性这几个抽象概念内化成直觉遇到任何HTML页面第一反应是找到它的稳定节点和稳定属性而不是急着写正则。7.2 刻意练习XPath的半衰期短写法写XPath时尽量少依赖绝对路径。每次写完我习惯问自己如果页面加了一层div这个表达式还能不能用如果不能马上改成相对路径稳定特征。7.3 在真实项目里积累反爬页面的解析经验反爬页面最喜欢搞的事情就是让解析器失效。比如随机换class名、加干扰节点、把真实数据隐藏到非标准属性里。我专门维护了一个解析对抗笔记每遇到一种新招就把应对策略记下来。这个笔记内容不便全部公开但有几个通用原则可以分享优先使用稳定的业务属性比如>