爬虫写得多了大家应该都有过这种体验目标数据明明就在 HTML 里但提取的时候要么取不到要么取多表达式写出来一跑就是空列表。尤其是那种嵌套层级深、class 属性乱、还有动态加载节点的复杂页面正则和 BeautifulSoup 往往写着写着就力不从心。我自己的经验是这类场景下 XPath 反而是最稳的解析方案——它把定位这件事变成了描述路径 条件表达式复杂逻辑一行就能说清楚。这篇文章适合已经能写基础爬虫、但对页面解析精度不满意的人。我会从 XPath 的核心语法讲起用一段模拟的复杂商品列表页做实战拆解再把我调试 XPath 时踩过的坑和排查方法一起整理出来。整篇都是我在 Python 爬虫项目里实际验证过的写法你可以直接照着抄。1. 复杂 HTML 场景下为什么 XPath 是最稳的解析方案1.1 正则的局限性它根本不理解页面的层级关系很多新手一开始用正则提取数据因为它看起来最直接rspan classprice(.*?)/span一写似乎就拿到了。但 HTML 本质是一棵嵌套的文档树正则却是平铺的文本匹配。一旦遇到标签嵌套、同类名重复、属性顺序变化正则表达式的可读性和稳定性会迅速崩盘。举一个很常见的例子某个页面里div classitem内部又嵌套了一层div classitem你想提取的是外层 item 里的价格。正则的贪婪匹配会直接跨到下一个价格标签非贪婪匹配又可能被内层结构截断。再加上 HTML 本身经常不按规范写标签没闭合、引号单双混用正则表达式在这种场景下几乎是修不完的坑。正则适合什么适合从接口返回的纯文本、日志字符串里捞固定格式的数据。拿它去解析 DOM 结构属于用错了工具。1.2 BeautifulSoup 的灵活性与它的边界在哪里BeautifulSoup 的find、find_all确实比正则人性化得多尤其是依赖class_、id这些属性去定位时代码很直观。但大型复杂页面里它的短板也会暴露出来定位条件复杂时方法链会很长。比如找到 class 包含 item 且>/html/body/div[1]/div[2] # 绝对路径从根节点一层层下去 //div[idproduct-list] # 相对路径全文档找 id 为 product-list 的 div//在复杂页面里很有用因为很多时候你并不关心目标节点在第几层嵌套只要它有特征就行。但也要注意性能//是全文档扫描数量多了会有开销所以能用上下文缩小范围就尽量缩小。还有几个常用符号.表示当前节点..表示父节点。*匹配任意元素节点*匹配任意属性。node()匹配任意类型的节点包括文本、注释等。//div[idlist]/* # list 容器下的所有直接子元素 //div[classitem]/.. # class 为 item 的 div 的父节点2.2 谓词筛选属性、索引、文本条件一次讲清谓词就是方括号里的条件这是 XPath 精准定位的核心能力。按属性筛选//div[idproduct-list] //span[data-typeprice] //a[href]后面跟属性名等于号后面是属性值。要注意属性值默认区分大小写要用精确匹配。按索引筛选XPath 的索引从 1 开始这点和 Python 完全不同是新手最容易踩的坑。//div[classitem][1] # 第一个 class 为 item 的 div //div[classitem][last()] # 最后一个 //div[classitem][position()3] # 前两个last()表示最后一个position()表示当前节点在其父节点中的位置。按文本内容筛选//span[text()现货] //a[contains(text(), 详情)]如果文本节点前后有空格、换行直接text()匹配容易失败所以更推荐配合函数清理下文会讲。组合条件//div[classitem and data-typenormal] //div[classitem or classproduct]2.3 内置函数与轴处理动态 class、相邻兄弟节点和祖先节点复杂页面里最常用的几个函数是contains()、starts-with()、normalize-space()和string()。contains(class, item)class 属性包含某个字符串即可。这是处理 HTML 多 class 的标准方式因为classitem hot active这种写法里你想匹配 item 就不能用精确等于。starts-with(class, product)开头匹配适合动态生成后缀的 class。normalize-space(//span)清理首尾空白和连续空白适合处理 HTML 里换行缩进产生的杂散文本。string()把节点内容转成字符串适合获取一段混合文本的完整内容。XPath 的轴axis用来表达从当前节点出发在文档树某个方向上的节点集合。复杂定位经常用到following-sibling、preceding-sibling、ancestor、descendant这几个。//span[text()价格]/following-sibling::span[1] # 价格标签同一父节点下的第一个兄弟 span //div[classitem]/ancestor::div[idcontainer] # item 向上找 id 为 container 的祖先轴的理解是 XPath 进阶的分水岭。处理表格、卡片式列表、评论区这种一个标签描述字段名、旁边标签才是字段值的结构时following-sibling比任何其他方案都干净。3. 复杂页面实战从一个模拟商品页拿到结构化数据3.1 页面结构拆解看看复杂页面到底复杂在哪为了把问题说透我准备了一个模拟商品列表页的 HTML 片段。这不是某个真实网站的页面但它的结构集中体现了复杂页面常见的痛点多层嵌套、同类名复用、部分字段缺失、动态加入的标签。div idproduct-list div classproduct-item>from lxml import html page_source open(product_list.html, encodingutf-8).read() tree html.fromstring(page_source) items tree.xpath(//div[idproduct-list]/div[contains(class, product-item)]) results [] for item in items: sku item.xpath(data-sku) title item.xpath(.//div[classtitle]/text()) price item.xpath(.//span[classprice]/text()) # 库存状态有两种可能用联合表达式统一处理 status item.xpath(.//span[contains(class, stock) or contains(class, soldout)]/text()) tag item.xpath(.//span[contains(class, tag)]/text()) results.append({ sku: sku[0] if sku else , title: title[0].strip() if title else , price: price[0] if price else , status: status[0] if status else , tag: 、.join(tag), })几个非常关键的细节第一个 xpath 我用了//div[idproduct-list]/div[...]而不是直接全文档搜索//div[contains(class,product-item)]。因为id在页面里应该是唯一的用它缩小范围后再向下定位既能避免误匹配其他模块里同 class 的节点性能也好很多。定位 title 和 price 时用了.//这个点号开头的相对路径表示从当前 item 节点往下搜索。如果不加这个点XPath 会从整棵树重新搜索结果可能取到别的商品卡片的字段数据就错位了。提取出的xpath()返回的都是列表即使只有一个匹配也要取[0]并且先判断非空。这是解析代码最常见的崩溃点。3.3 动态渲染场景Selenium 里的 XPath 配合显式等待很多复杂页面本身是前端脚本渲染出来的直接拿页面源码去解析XPath 什么都匹配不到。这种时候我会改用 Selenium 或类似工具拿到渲染后的 DOM再执行 XPath。Selenium 定位元素的核心 API 是find_element(By.XPATH, ...)用法很直接from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() driver.get(目标页面地址) # 显式等待最多 10 秒直到列表出现了再往下走 wait WebDriverWait(driver, 10) item_list wait.until(EC.presence_of_element_located((By.XPATH, //div[idproduct-list]/div[contains(class, product-item)]))) items driver.find_elements(By.XPATH, //div[idproduct-list]/div[contains(class, product-item)]) for item in items: title item.find_element(By.XPATH, .//div[classtitle]).text price item.find_element(By.XPATH, .//span[classprice]).text这里有个隐性但很重要的点Selenium 里每个元素节点再次调用find_element(By.XPATH, ...)时XPath 前面一定要加.表示从当前元素节点范围内搜索。如果不加浏览器会从整份文档寻找很可能取到其他卡片的数据。显式等待配合 XPath 还有一个好处可以等一个动态出现的节点而不是写死sleep(5)。网络慢的时候sleep不够网络快的时候又浪费几秒显式等待是更可靠的方案。4. 调试与避坑XPath 写出来却匹配不到怎么办4.1 先把失败原因分个类才能对症下药我调试 XPath 的时候遇到匹配不到或匹配错位的情况通常先按这几类排查第一类你看到的页面和解析用的源码不是同一个 DOM。浏览器里按 F12 看到的已经是 JavaScript 执行完的状态而你用 requests 拿到的是服务端返回的原始 HTML。这两者不一致时XPath 在原始 HTML 里匹配不到太正常了。第二类class 多值导致的匹配失误。页面里写classproduct-item active你写成classproduct-item精确匹配肯定取不到。要用contains(class, product-item)但同时也要小心product-item和product-item-list这种包含关系引起的误匹配。第三类属性值的大小写和不可见字符。HTML 属性值大小写敏感>from lxml import html with open(page_debug.html, encodingutf-8) as f: tree html.fromstring(f.read()) # 先验证最外层容器能不能选中 container tree.xpath(//div[idproduct-list]) print(len(container)) # 再验证每一条 XPath 的结果数量 print(tree.xpath(count(//div[idproduct-list]//span[classprice])))用count()函数直接看匹配数量比肉眼数节点快得多。定位到是哪一步表达式返回空列表问题就暴露了一大半。如果有浏览器环境Chrome DevTools 的 Console 里可以直接输入$x(//表达式)能够立刻在浏览器渲染后的 DOM 上验证表达式。注意它验证的是渲染后的 DOM如果确认渲染后能匹配但代码里取不到问题基本就锁定在源码和渲染 DOM 不一致这一项了。4.3 把表达式写得健壮降低对页面细节的依赖调试经验积累下来我总结了几条让 XPath 不那么脆弱的写法习惯优先用稳定的属性定位比如id、data-sku这类属性在页面改版时相对不太变化不要依赖肉眼可见的文本内容做定位文案一改表达式就失效。能用相对路径语义的地方别写死深层的绝对路径。//div[contains(class, item)]比/html/body/div[3]/div[2]/...稳定得多前端结构调整后绝对路径基本必挂。对可能缺失的字段用or 或非空判断兜底不要指望每个 item 结构完全一致。避免用太泛的contains(class, ...)。如果页面上还有其他模块的 class 也包含同样关键词建议叠加父级容器或其他条件来缩小范围。索引定位要谨慎[1]、[last()]这类依赖顺序的写法最好在实在找不到特征属性时再用。5. 性能与代码组织把解析逻辑做成可复用的模块5.1 预编译 XPath 表达式批量采集时能省不少时间如果只是单页解析直接tree.xpath()没什么问题。但批量采集成百上千个页面时重复解析相同字符串的开销会被放大。lxml 提供了预编译机制把表达式字符串提前编译成可重复调用的对象。from lxml import etree # 预编译 XPath 表达式 item_path etree.XPath(//div[idproduct-list]/div[contains(class, product-item)]) title_path etree.XPath(.//div[classtitle]/text()) price_path etree.XPath(.//span[classprice]/text()) for source in page_sources: tree html.fromstring(source) items item_path(tree) for item in items: title title_path(item) price price_path(item)预编译之后重复查询同一表达式的效率会有明显提升。尤其当同一个页面要提取几十个字段、表达式本身又复杂时这个优化很值得。5.2 把 XPath 写成配置解析逻辑和数据模型分离做了一段时间爬虫后我养成了一个习惯把 XPath 表达式集中放到一个配置字典里而不是散落在业务代码各处。这样目标页面改版时只需要改配置不用动核心逻辑。PRODUCT_XPATH { container: //div[idproduct-list]/div[contains(class, product-item)], title: .//div[classtitle]/text(), price: .//span[classprice]/text(), status: .//span[contains(class, stock) or contains(class, soldout)]/text(), tags: .//span[contains(class, tag)]/text(), } def parse_product_page(page_source, config): tree html.fromstring(page_source) items tree.xpath(config[container]) parsed [] for item in items: row {} for field, expr in config.items(): if field container: continue values item.xpath(expr) row[field] values[0].strip() if values else parsed.append(row) return parsed这个写法把提取哪些字段和怎么提取变成了一份配置。字段结构变化时只改字典需要新增字段时加一行表达式。维护成本肉眼可见地降低。5.3 和 CSS 选择器配合什么时候用 XPath什么时候用 CSSlxml 也支持 CSS 选择器通过cssselect模块可以写.cssselect(div.product-item div.info)这种形式。我的取舍标准是场景推荐方式原因按某个 class/id 直接定位元素CSS 选择器语法更短可读性好需要按文本内容、属性函数过滤XPath原生支持contains、starts-with需要沿文档树找兄弟、祖先节点XPathCSS 对这些几乎没有表达能力需要批量提取文本、统计数量XPathcount()、text()直接搞定动态渲染后 Selenium 定位XPath配合显式等待最顺滑也更清晰我的经验是定位单个元素用 CSS 省事涉及条件逻辑和文档关系就切到 XPath。两者互补比死磕某一种工具舒服得多。最后分享一个我在实际调页面时的小技巧写完一条 XPath先别急着写进完整代码里。先用一小段 Python 脚本把表达式和结果数量打出来看一遍确认无误再整合进采集逻辑。这种方式看起来多了一步但能帮你在一开始就过滤掉大部分表达式看着对、跑起来空的问题。页面结构复杂不可怕怕的是定位逻辑写得含糊。把每条 XPath 都拆到能明确回答它到底在找什么的程度复杂 HTML 页面也就没有秘密了。