企业官网建设流程全解析

1. 先搞清楚：为什么“相同标签”会让人头疼

做网页爬虫、UI自动化测试或者用RPA工具抓数据的朋友，大概率都遇到过这种情况：打开F12一看，页面上整整齐齐躺着十几个<div>，每个长得都差不多；或者一个表格里七八个<span>，你想点的偏偏是第三个。更气人的是，有些页面的标签连class都是重复的，比如一堆<i class="icon">排在一起，你想精准定位其中某一个，用普通的XPath怎么写都不对。

这个问题的本质其实不是“XPath不好用”，而是你还没想清楚一件事——你凭什么把这十几个相同标签区分开。XPath的定位逻辑从来不是“我要找那个div”，而是“我要找一个满足这些条件的节点”，条件给得越严格，定位就越准。相同标签之所以难定位，是因为标签名本身失去了区分度，你必须要从别的维度去找差异。

这一篇我先讲最核心的几种思路，不是给你背语法，而是带你把“定位相同标签”这件事彻底想明白。看完你至少能解决80%的同类问题。适合刚接触XPath的爬虫新手、写自动化脚本的同学，以及所有被动态页面折磨过的人。

在这里我默认你已经会用基础的XPath，比如//div代表“找所有div”，/和//的区别你也清楚。如果还不太熟，建议先花十分钟把基础语法过一遍，再回来看这篇，效果会好很多。

2. 基础定位：三种拿来就能用的XPath写法

2.1 index定位：数人头，但要明白它为什么脆弱

既然标签一样，第一个最朴素的想法就是——“我要第几个”。XPath里用谓词[n]来数位置，写法是：

<ul> <li>苹果</li> <li>香蕉</li> <li>橙子</li> <li>西瓜</li> </ul>

如果你想定位“橙子”，可以用：

//ul/li[3]

注意这里有个特别容易踩的坑：XPath的index是从1开始的，不是从0开始。很多写代码的人习惯了编程语言的0基索引，第一反应写li[0]想拿“苹果”，结果返回空或者直接报错。这个坑我见过无数人踩过，包括我自己早期写爬虫的时候也中招过。

那//li[3]可不可以？不推荐。因为//会把你放到文档里的任意层级，如果页面里还有别的<li>列表，这个表达式找的是整页所有li里的第三个，不一定是你想定位的那个。所以index定位最好是配合层级路径一起用，缩窄范围之后再数数。

再说说index定位的致命弱点——它依赖顺序。现在看起来li[3]是橙子，明天产品经理把列表排序改了，橙子变成了第四个，你的脚本就直接扑街。所以在实际工作中，我一般把index定位当作“最后的手段”，能用属性或文本就别用纯序号。

index还有几个变体值得记一下：

//li[last()] —— 最后一个li //li[last()-1] —— 倒数第二个li //li[position()<3] —— 前两个li //li[position()>2] —— 从第三个开始后面的所有li

这几个在特定场景下很好用。比如你想拿列表的最后一项，但列表长度是动态的，这时候last()就比硬编码数字靠谱得多。

这里再补充一个细节：如果同一层级里夹杂着其他标签，li[3]只数li，不会把div、span算进去。XPath的[n]是“同类节点中的第n个”，不是“所有子节点中的第n个”。这个理解起来有点绕，你只要记住“它按标签名分组数数”就行。

2.2 属性定位：最常用的方案，但类名要小心用

比数人头靠谱的做法是找属性差异。XPath里通过标签的属性来筛选节点，是最常见的写法：

//input[@id='username'] —— 通过id定位 //button[@class='btn-primary'] —— 通过class定位 //a[@href='/login'] —— 通过href定位 //input[@placeholder='请输入手机号'] —— 通过placeholder定位

理论上说，任何HTML属性都能拿来定位：id、class、name、type、value、placeholder、><div class="item active">1</div> <div class="item">2</div> <div class="item">3</div>

这里三个div都有item这个class，但只有第一个还有active。如果你用//div[@class='item']，会一下命中三个。但如果你用//div[@class='item active']，就只能命中第一个——注意，这里的class属性值是完整字符串，'item active'是一个整体，顺序都不能换。如果HTML里写成class="active item"，你再用@class='item active'就匹配不上了。

那遇到这种“多个class，我只想要其中一个”的情况怎么办？XPath提供了contains函数：

//div[contains(@class, 'item')]

这个写法会匹配所有class属性里包含item字符串的元素。class="item active"能匹配上，class="item"也能匹配上，class="active"就不能。

不过contains(@class, 'item')也有一个隐蔽的坑：如果你要匹配的关键词很短，很容易误伤。比如你想定位class="item"，但页面上还有个class="item-wrapper"，contains也会把它捞出来。所以实际用的时候，关键词尽量取得有辨识度，或者前后加上空格去匹配：

//div[contains(concat(' ', @class, ' '), ' item ')]

这个写法是先在class属性值的前后各加一个空格，再去查找“前后都有空格的item”。它能精确匹配独立完整的item这个类名，而不会误伤item-wrapper。代码里稍微绕一点，但确实是处理多class最稳的方案。

2.3 层级配合：先锁父级，再找后代

还有一种情况，你想要的标签本身没什么特别属性，但它的父级、兄弟节点有。这时候就可以先定位好认的那个元素，再通过层级关系找目标。

比如这个结构：

<div class="product-item"> <div class="product-name">蓝牙耳机</div> <div class="product-price">299</div> <div class="product-buy"> <button>加入购物车</button> <button>立即购买</button> </div> </div>

现在你想定位“立即购买”这个按钮。两个<button>标签一样，没有属性区分。但你可以先锁住product-buy这个容器，再往下找button：

//div[@class='product-buy']/button[2]

或者更简单，直接用后代关系：

//div[@class='product-buy']//button[last()]

这种“先父后子”的思路，是解决相同标签问题的核心方法论。它能把你需要定位的范围一步步缩小——先锁住一个不容易重复的容器，然后在容器内部进行index定位或进一步筛选。相当于先找到房间号，再在房间里数座位，而不是在整个体育场里靠数人头找座位。

层级配合还有一个常见场景：父级没有class怎么办？那就继续往上找爷爷级，找一个能稳定识别的祖先节点，然后再往下走。成本就是从下往上多写几层，但稳定性会高很多。

这里面要注意一个细节：/和//的区别。/button要求button必须是当前节点的直接子元素；//button则允许button是任意层级的后代。如果你的目标元素嵌套比较深，用//更省事，但可能捞到范围更大的结果；用/更精准，但对结构层级要求更严格。实际使用中可以两个都试一下，看哪个匹配结果干净。

3. 进阶：文本定位与模糊匹配的实战细节

3.1 精确文本匹配与常见空格坑

有些标签确实啥属性都没有，但长得不一样——不一样的在于里面的字。这时候就可以用文本内容来定位。XPath里匹配文本的函数主要有两个：text()和string()。

先看最基本的精确匹配：

<button>登录</button> <button>注册</button>

定位登录按钮：

//button[text()='登录']

这个写法的含义是：找所有button，筛选出文本内容等于“登录”的那个。看起来很简单，但实际页面里经常出问题。

第一个坑是空白字符。很多人写HTML的时候，标签里有换行缩进：

<button> 登录 </button>

这时候text()的值实际上是\n 登录 \n，而不是干干净净的“登录”。你用text()='登录'去匹配，等于白写。这种情况常出现在一些排版比较乱的页面上，尤其是老项目或者后台管理系统。

解决的思路有两个：一个是容忍空白，用contains模糊匹配；另一个是先用normalize-space()函数把前后的空白清掉，再精确匹配：

//button[normalize-space(text())='登录']

normalize-space()会把首尾空白去掉，还会把连续的多个空格合并成一个，这样就不怕页面排版带来的干扰了。

第二个坑是复合文本。有的元素内部不只有一个文本节点，比如：

<span>价格：<em>99</em>元</span>

这个span里面其实有“价格：”、“元”和嵌套的em里的“99”三个部分组成。你用span[text()='价格：99元']是匹配不上的，因为你只匹配了span的直接文本节点，而“99”并不属于span的直接文本节点。

这时候用string()函数就能解决：

//span[string()='价格：99元']

string()会取元素的完整字符串内容，递归地把所有子节点的文字拼在一起，而不是只看直接文本节点。理解了这个区别，你就能解释为什么有时候text()不好使，换string()就好了。

3.2 contains与模糊匹配的取舍

除了精确匹配，你还会遇到一种情况：你要定位的元素文本内容不是固定的，但其中一部分关键字是固定的。比如商品价格实时变，但“¥”这个符号不变；或者一个按钮的文案是根据用户行为动态拼接的，但前缀固定。这时候就需要模糊匹配。

//span[contains(text(), '¥')]

上面这句能匹配所有文本里包含“¥”符号的span。再比如你想找所有“加入购物车”相关的按钮，不管它后面跟的是什么商品名：

//button[contains(text(), '加入购物车')]

contains确实方便，但它的代价是可能匹配到你不想找的东西。比如你找“管理”按钮，结果“管理员设置”的链接也被捞上来了。所以在使用模糊匹配的时候，关键字尽量选得具体一些，最好是那种不太可能出现在别处的词组。

还有一点需要提醒，contains的用法不止能用在text()上，还可以用在属性上：

//input[contains(@placeholder, '手机号')] //div[contains(@class, 'product')] //img[contains(@src, 'logo')]

甚至可以同时用多个contains条件来进一步缩小范围：

//button[contains(@class, 'btn') and contains(text(), '确认')]

这个写法的意思是：找class里含有“btn”、文本里含有“确认”的按钮。多个条件叠加，最终命中的范围就非常精确了。搭配上逻辑运算的and、or，你能组合出很多灵活的定位表达式。

有一种场景我特别建议用模糊匹配：文本里带数字、带时间戳的元素。比如“共12条记录”“更新于2024-06-15 14:30”这种，精确匹配完全没法用，因为数字一直在变。你把稳定不变的文字部分拿出来做contains，就能稳稳定位到。

4. 同一标签大量出现时：用逻辑关系缩小范围

4.1 结合“位置+条件”的组合定位

在实际页面上，你面对的往往不是“三五个相同标签”，而是“几十个相同标签”。比如商品列表页，每个商品卡片结构都一样，里面都有价格、标题、销量。你爬数据的时候，只取第一条可能不够，你得遍历所有商品卡片。

这种场景下，核心思路不是“怎么定位某一个”，而是“怎么把共同的父级容器锁住”。

比如每个商品卡片的HTML长这样：

<div class="goods-item"> <div class="title">机械键盘</div> <div class="price">399</div> </div> <div class="goods-item"> <div class="title">显示器</div> <div class="price">1299</div> </div>

你完全可以先定位所有goods-item：

//div[@class='goods-item']

拿到这一组元素之后，再在每个元素内部去定位title和price：

//div[@class='goods-item'][1]//div[@class='title'] //div[@class='goods-item'][2]//div[@class='price']

这里的[1]和[2]仍然是index，但它的含义已经不同了——它是在“同一父级下的同class节点”里挑序号，而不是在整个文档里数。再配合内层的条件，可读性和稳定性都会好很多。

还有一种组合是“位置+文本”一起用。比如一个导航栏有五个标签，结构完全一样，但你想选第三个，同时又想确认它确实是“产品中心”：

//ul[@class='nav']/li[3][contains(text(), '产品')]

这个写法相当于：在nav下取第三个li，并且要求它包含“产品”。如果第三个li不是“产品”，这个表达式会返回空，这样你就能马上知道页面结构变了，而不是错定位到别的元素上。

这种“组合条件”的思路，本质上是给定位加保险。你每多加一个条件，就多一层确认，错误定位的概率就小一分。

4.2 判空与避免踩中隐藏元素

另一个处理大量相同标签时经常遇到的问题：页面上会同时存在隐藏元素和显示元素。有些弹窗、轮播图、下拉菜单的DOM始终在页面里，只是被CSS或display:none藏起来了。你用XPath去定位，会同时捞到隐藏的和显示的，造成干扰。

比如一个页面上有多个<div class="modal">，其中一个是正在展示的弹窗，其余几个是历史遗留的隐藏弹窗。你写//div[@class='modal']拿到的结果有好几个，你也不知道哪个是哪个。

这种情况下可以用XPath的visible判断吗？XPath本身不直接支持“判断元素是否可见”，但你可以通过检查某些属性来间接判断。比如弹窗通常会有style="display: none;"隐藏，那就可以排除掉含有display:none的元素：

//div[@class='modal' and not(contains(@style, 'display: none'))]

这是一个比较“脏”但实战中有效的做法。更干净的方式是在拿到元素列表之后，用你所在的语言框架去过滤可见性。比如在Selenium里每个元素都有is_displayed()方法；在爬虫的HTML解析库里，你可以自己模拟判断——总之，XPath先把范围缩小到一个候选集合，可见性判断放到代码层处理，分工合作，效率更高。

再说说“判空”。很多初学者在定位的时候，写了一个XPath路径，拿不到结果，第一反应是觉得路径写错了。其实更常见的原因是你锁定的那一组元素里，某些元素本身是空的。比如你用的是：

//div[@class='goods-item']//div[@class='title']

如果有几个商品卡片没有title，这条路径的匹配结果就可能少于预期。这时候你需要在代码里加一层判空逻辑：拿到元素列表后先判断长度，再逐个处理，避免索引越界或者None报错。

关于这个场景我还要多说一句：如果你的目标是遍历所有同类元素，尽量不要用绝对路径。绝对路径/html/body/div[2]/div[3]/...一旦页面结构发生一点小变动就会失效，而且很难读懂。相对的，基于class和层级关系写的相对路径，哪怕中间多嵌套了一层，只要关键class没变，通常还是能正常工作。

5. 常见问题与排查技巧实录

5.1 为什么我写的XPath在浏览器控制台能查到，脚本里却找不到？

这是出现频率最高的问题。你在浏览器开发者工具里用$x('//div[@class="title"]')能查到，或者在线XPath测试工具里验证也通过，但一跑到代码里就报错。

原因多半是命名空间或者上下文对象的问题。浏览器控制台执行XPath的时候，作用于整个HTML文档；而有些脚本框架（比如某些Python的HTML解析库）要求你从某个特定节点开始搜索，或者需要调整XPath路径的起点。还有一种情况是页面里嵌了iframe，你在主文档里写的XPath当然进不去iframe内部。遇到这种情况，需要先用代码切换到iframe的上下文，再执行定位。

另一个常见原因：执行的时刻不对。页面里的元素是JavaScript动态渲染的，你的XPath写的是渲染完成后的结构，但脚本执行时元素还没生成。解决方法是在执行定位之前加显式等待——不是盲目sleep几秒，而是轮询等待目标元素出现，这样更稳也更快。

5.2 为什么class明明有值却匹配不上？

对照前面讲的@class匹配逻辑，我帮大家梳理了一张速查表，按优先级记忆就行：

这张表你可以截图存一下。我在实际调试中遇到的大部分class匹配问题，用最后两种写法基本都能解决。

5.3 为什么定位总是命中第一个元素？

如果你写的是//button[contains(text(), '确认')]，但页面上有两个按钮都包含“确认”，那这个XPath默认返回的是文档顺序中的第一个。很多框架的find_element就是取第一个匹配元素，如果你没意识到这一点，就会莫名其妙地操作到错误的按钮上。

这时候你要么把条件写得更严格，让它只匹配唯一一个；要么用find_elements拿到全部匹配项，然后通过下标选择你真正需要的那个。我个人的习惯是：能通过条件精确缩窄到唯一一个就绝不靠下标，下标是最后的兜底手段。

5.4 推荐一套我常用的调试流程

每次遇到XPath定位不到，我基本按这个顺序排查，效率很高：

1. 先在浏览器控制台验证：用$x('你的表达式')执行一下，看匹配结果是否为空、匹配数量是多少。
2. 检查页面结构是否动态渲染：右键点目标元素，选择“检查”，看HTML里是否存在；有时需要刷新页面、滚动页面才能看到真实结构。
3. 缩小匹配范围：如果表达式匹配到多个，逐步增加限制条件，比如加上父级路径、加上文本或属性条件。
4. 切换上下文：确认元素不在iframe里，或者在shadow DOM里，处理方式完全不同。
5. 在代码里打日志：把XPath查到的元素数量打印出来，方便判断是匹配失败还是后续处理逻辑出错。

这套流程我用了很多年，不管是在写爬虫还是做自动化测试，都能在三五分钟内定位到问题根因，而不是靠瞎改路径碰运气。

还有一个小技巧分享给你：浏览器控制台里$x返回的是数组，即使只有一个元素也以数组形式返回。想快速确认你的XPath是否唯一命中，可以看返回数组的length，如果大于1就要警惕了。这个细节能帮你提前发现“你以为选对了、其实选了一堆”的隐患。

6. 关于下一篇，先给你留个引子

其实XPath能处理相同标签的手段远不止这些，比如following-sibling、preceding-sibling、parent、ancestor这些“轴”定位，在处理复杂表格和列表时简直是神器；再比如xpath结合正则式的matches函数，能玩出很多花样来。

这些内容我放到“（二）”里继续讲。你先把这一篇的基础方法练熟，尤其是先缩小范围再定位的思路，这比记住任何具体的路径写法都重要。

最后多唠叨一句：XPath写得好不好，不在于背了多少函数，而在于你会不会观察页面结构。多花三十秒看DOM树，好过瞎试半小时路径。