企业官网建设流程全解析

做自动化的人大概都经历过这么一个瞬间：一段脚本在自己电脑上跑得好好的，换台机器、换个分辨率，或者 APP 隔天更新了一次，定位就集体失效了。我上个月就遇到过一次，某开发者发来一段两百多行的脚本，满屏都是//android.widget.TextView[@text='立即抢购']这种写法，问他为什么这么写，回答是“录制工具生成的”。问题在于，页面上叫“立即抢购”的按钮可能有三四个，录制工具只会告诉你“能点”，不会告诉你“为什么能点、什么时候不能点”。这就是大多数人对 XPath 的全部认知——知道它存在，会用最简单的//标签[@属性='值']，但从来没真正理解过它。

XPath 本质上是 XML/HTML 文档树上的路径语言，你可以把它理解成文件系统里的路径，只不过这个“文件系统”里的节点可以有多个同名兄弟、可以有属性、可以按文本内容筛选、还能向上回溯和横向平移。它解决的问题非常具体：在结构不完全确定、属性部分动态、层级又很深的文档里，精确地挑出你想要的那一个或那一批节点。用得上它的人比想象中多——爬虫工程师、UI 自动化测试、APP 界面的元素定位、数据清洗时从 HTML 片段里抽字段、甚至运维去解析某些配置文件，都绕不开它。这篇内容从最基础的路径语法讲到轴和函数的组合用法，最后拿一个本地生活类 APP 的真实页面层级做一遍匹配演练，中间穿插我自己踩过的坑和几条工程化经验。

1. 元素定位这件事，为什么我最后还是回到 XPath

1.1 几种定位方式的横向对比与取舍逻辑

新手最常问的问题是“有 id 为什么还要用 XPath”。这个问题本身问反了，正确的问法是“什么时候 id 靠不住”。在 Web 端，id 通常还算稳定；到了移动端，尤其是混合渲染的页面，id 经常是动态生成的，形如btn_8f3a2c、item_1729，每次渲染都变。class 更惨，某些前端框架打包后 class 会变成a1b2c3这种无语义字符串。文本定位看起来最直观，但多语言、多端文案微调、运营活动期间文案天天换，都是硬伤。

我把常见的定位方式列了个对照，这是我在多个项目里反复权衡后形成的判断：

结论不是“XPath 最好”，而是“XPath 是兜底能力最强的那一个”。CSS Selector 只能向下走，选不了父节点，也没有文本匹配（:has-text那类非标准扩展不能指望跨环境通用）；XPath 能向上、能横向、能算字符串、能做逻辑组合。所以我的策略一直是：能用 id 就用 id，id 不稳就退到 XPath，而 XPath 里优先用结构关系而不是绝对路径。

1.2 版本差异：1.0 和 2.0 之间隔着一整个工具箱

这个坑我必须提前说，因为它导致过我最长一次排查。XPath 1.0 和 2.0/3.0 的函数集差别很大，而绝大多数运行环境默认给你的是 1.0。浏览器里的document.evaluate只支持 1.0；Python 的lxml默认 1.0；移动端自动化框架基于系统原生解析器，基本也是 1.0 的子集。

差别体现在哪？最典型的就是ends-with()。这是 XPath 2.0 的函数，你在浏览器控制台里写//div[ends-with(@class,'active')]，得到的不是结果，是一句Invalid XPath expression。同理还有matches()正则匹配、lower-case()、upper-case()、replace()、tokenize()，全部是 2.0 才有的东西。我见过有人在脚本里写了一堆matches()，本地用某个支持 2.0 的库跑通了，一上生产环境全炸。

1.0 里想做“以某某结尾”，只能用substring()配string-length()拼出来。想要大小写不敏感，只能用translate()手动映射。这些写法丑，但它们是跨环境的通用解，后面第 3 章我会给出具体模板。

1.3 场景拆解：一个本地生活类 APP 的页面长什么样

为了让后面的例子有落点，我先虚构一个页面结构。假设我们面对的是一个本地生活类 APP（下文简称“生活 APP”），首页从上到下是：顶部搜索框、分类入口宫格、限时活动横幅、商家推荐列表。商家卡片里包含店铺名、评分、月售、配送费、几个标签（比如“免配送费”“新客立减”）、一个“去下单”按钮。点进店铺后弹出一个规格选择浮层，里面有规格选项和“加入购物车”按钮。

这类页面的共同特征决定了 XPath 的写法取向：第一，列表项是复用的同一个模板，只有索引不同，所以定位必须能区分“第几个”；第二，价格、月售这类数字文本每次刷新都变，不能拿来做精确匹配；第三，标签文案是运营配的，可能带前后空格甚至全角空格；第四，浮层和主页面可能同时存在于节点树里，需要靠层级关系区分。

这四点对应的就是后面要讲的：位置谓词、模糊文本匹配、normalize-space()、以及轴定位。先把基础打牢，这些才有意义。

2. 基础语法：把节点树这件事真正想明白

2.1 节点、轴、谓词：XPath 的三个基本零件

任何一条 XPath 表达式，拆开来看都只有三个零件：轴（axis）决定“往哪个方向找”，节点测试（node test）决定“找什么样的节点”，谓词（predicate）决定“在候选里筛哪些”。写成公式就是轴::节点测试[谓词]。

大部分人写//div[@class='card']的时候并没有意识到自己在写轴，其实//就是descendant-or-self::node()的缩写，div是节点测试，[@class='card']是谓词。理解了这层，你才能明白为什么//有性能代价——它会把整棵树的每一层节点都遍历一遍。在一个几千节点的 UI 层级里，//开头的表达式比//父节点/子节点形式慢得多，因为后者在第一层就能把候选集砍掉大半。

轴一共 13 个，日常真正高频的其实就六七个：child（默认，可省略）、descendant、parent、ancestor、following-sibling、preceding-sibling。剩下像following、preceding、attribute、namespace用得少但偶尔救命。我建议初学阶段先记住..是parent::node()的缩写、.是self::node()的缩写，这两个简写能在关键时刻省很多事。

2.2 绝对路径、相对路径与那个必须记住的括号

/开头是绝对路径，从文档根节点开始算，//开头是相对路径，从任意位置开始搜。这个大家都知道，但下面这个差异知道的人就少一些：

• //div[1]的含义是“每一个父节点下的第一个 div 子节点”，注意是“每一个父节点”；
• (//div)[1]的含义才是“整个文档里的第一个 div”。

差别的原因在于谓词的作用域：写在节点测试后面的谓词，作用于当前步骤选出的每一个节点的兄弟集合；加了括号之后，整个表达式的结果被当作一个新的节点集，谓词才作用于全局。这个规则我第一次遇到时吃了大亏——想取列表的第一项，写成了//div[@class='item'][1]，结果返回了一堆元素，因为列表的每一层嵌套里都各有一个“第一个 item”。

正确的写法是(//div[@class='item'])[1]。同理，取最后一个用(//div[@class='item'])[last()]，取前三个用(//div[@class='item'])[position()<=3]。

2.3 属性匹配的四个层级：从严格等于到模糊包含

属性匹配是入门第一课，但真正用好的关键是知道什么时候不该用等号。我把它们分成四档：

第一档，严格等于：[@resource-id='com.example.localapp:id/search_box']。只在属性值完全确定时用，一旦值里多一个空格、或者末尾多了一串动态后缀，立刻失效。

第二档，包含：[contains(@resource-id,'search_box')]。这是最常用的写法，能吃掉前缀包名变化和后缀动态串。但它有误匹配风险——search_box和search_box_container都会被命中。

第三档，前缀匹配：[starts-with(@resource-id,'com.example.localapp:id/')]。适合“前面的包名固定、后面变化”的场景，比contains更安全一点。

第四档，多值属性的精确包含。这是 class 属性专用的技巧。HTML 里的class="btn btn-primary large"是空格分隔的多个值，直接[@class='btn']匹配不到，contains(@class,'btn')又会误中btn-primary。标准解法是两头补空格：

[contains(concat(' ', normalize-space(@class), ' '), ' btn ')]

normalize-space()负责清掉首尾空白并把中间连续空白压成一个，concat在两头补空格，这样变成btn btn-primary large去匹配btn，既不会漏也不会误中。这条写起来啰嗦，但我在列表页定位上用它之后，误匹配率基本降到零。

2.4 文本匹配与空白字符这个隐形杀手

[@text='加入购物车']这种写法，我敢说每个做自动化的人都被它坑过。文本里带一个换行、带一个不可见的\u00a0（不间断空格）、或者前后多了个缩进空格，表达式就整条失效。

normalize-space()用在这里同样有效，但要作用在节点上而不是属性上：[normalize-space(text())='加入购物车']，或者更宽松的[normalize-space()='加入购物车']（当只有一个文本子节点时，节点自身的字符串值就是这个文本）。

还有一个更隐蔽的坑：文本被拆成多个文本子节点。比如<span>加入<em>购物车</em></span>，text()只会拿到“加入”这一截。这时候要用[contains(., '加入购物车')]——点号代表节点自身的完整字符串值，会递归拼接所有后代的文本。代价是它可能匹配到外层的大容器节点，所以通常我还会再加一个层级约束，比如[contains(., '加入购物车') and not(*[contains(., '加入购物车')])]，意思是“包含这段文本，但子节点里没有包含同样文本的”，等价于取最内层的那个匹配节点。这个技巧在抓价格时特别好用，因为价格往往被拆成符号、整数、小数三段。

2.5 位置谓词与逻辑运算的优先级规则

位置谓词就是[1]、[last()]、[position()>2]这类，前面已经讲过[1]的陷阱，这里补充两个细节。last()在嵌套谓词里指的是当前上下文节点集的最后一个，不是全局最后一个；position()同理。所以在(//div[@class='item'])[position() mod 2 = 1]里，取出来的是第 1、3、5……项，用来做“隔行取”很方便。

逻辑运算的优先级顺序是or最低、and次之、比较运算符再次、最后是算术。这意味着[@a='1' and @b='2' or @c='3']会被解析成(@a='1' and @b='2') or @c='3'。这个顺序容易记混，我的习惯是永远加括号，宁可多打两个字符，也不要去赌解析器的实现。

3. 进阶：轴、函数与动态属性的组合打法

3.1 轴定位：从“往下找”变成“由已知推未知”

轴真正的价值在于，它能把“绝对位置”变成“相对关系”。举个生活 APP 里的典型场景：商家卡片上有个“免配送费”标签，我要点同一张卡片里的“去下单”按钮。你没法单纯靠属性定位到那个按钮，因为页面上有几十个一模一样的按钮，属性完全一样。但你换个思路：先定位到带“免配送费”文本的那个标签，再从它出发找相同的祖先容器，最后在容器内找按钮。

推演过程是这样的。第一步//*[@text='免配送费']定位到标签。第二步往上找最近的、class 是卡片的祖先：ancestor::*[contains(@class,'card')][1]，这里[1]之所以能用，是因为ancestor::轴返回的是逆序（由近及远），所以第一个就是最近的祖先。第三步在这个祖先范围内往下找按钮：descendant::*[@text='去下单']。

组合起来就是：

//*[@text='免配送费']/ancestor::*[contains(@class,'card')][1]//*[@text='去下单']

这里有一个容易忽略的点：ancestor::后面接//时，作用域已经切换到该祖先节点，所以它不会再跑到全文档里去匹配。这就是轴定位优于全量//的根本原因——它天然带着上下文约束，越长的表达式反而越精确、越快。

另一个高频轴是following-sibling。表单里“标签-输入框”成对出现时，可以写成//label[text()='手机号']/following-sibling::input。注意following-sibling只取同级的后续节点，如果输入框包在一个 div 里，就得用following::（取后续所有节点）或者先parent::再往下找。这两个轴的区别我建议动手验证一次，写过一遍就不会混了。

3.2 动态属性处理的四种实用套路

移动端和前端构建工具生成的属性值，大致有四种动态形态，对应四种解法。

形态一，前缀固定后缀随机：id="item_1729003"。用starts-with(@id,'item_')。

形态二，中间固定两头随机：class="x-a1b2-card-c3d4"。用contains(@class,'-card-')。

形态三，带分隔符且需要取某一段：id="list:1729:detail"。可以用substring-before(substring-after(@id,'list:'),':')把中间那段抽出来，再和期望值比较。这招在做“取当前项的序号”时很有用。

形态四，大小写不定：class="Card"或class="CARD"。XPath 1.0 没有lower-case()，只能用translate()做映射。把 A 到 Z 全部映射成小写：

[contains(translate(@class,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz'),'card')]

写起来确实长，但它是 1.0 环境里唯一可靠的大小写不敏感方案。我通常会把这段封装成一个常量字符串，在代码里拼接，避免手写出错。

顺带把 1.0 里的常用函数整理成一张速查表，这些都是我平时翻得最多的：

3.3 用 ends-with 的需求怎么在 1.0 里实现

单独把这个拎出来讲，因为它太常见了。需求是“id 以_submit结尾”，1.0 没有ends-with，标准解法是：

[substring(@id, string-length(@id) - string-length('_submit') + 1) = '_submit']

推一下参数：设 id 长度为 L，后缀长度为 7（_submit共 7 个字符），那么后缀的起始位置是 L - 7 + 1 = L - 6。substring从 L-6 开始取，一直取到末尾，长度自然是 7 个字符，正好等于后缀。这个 +1 是很多人写错的地方——substring的索引从 1 开始而不是 0，漏掉 +1 就会变成多取一位，永远匹配不上。

如果嫌长，还有个取巧写法：[contains(@id,'_submit') and not(contains(substring-after(@id,'_submit'),'_'))]，意思是“包含该后缀，且该后缀之后再没有下划线”，等价于它确实在末尾。但可读性更差，我个人还是用第一种。

3.4 组合查询：并集、排除与“取最内层”

|是并集运算符，可以把两组结果合并：//*[@text='确定'] | //*[@text='确认']。这在文案不确定的场景下很实用，一次定位拿两个候选，再在代码里取第一个可见的。

排除用not()：//*[@text!='']排除文本为空的干扰节点，//div[not(contains(@class,'hidden'))]排除隐藏元素。

“取最内层”前面提过一个写法，这里给个更简洁的版本：//*[@text='优惠券' and not(descendant::*[@text='优惠券'])]。它表示“自身文本是该值，且后代里没有同样的文本”，结果是唯一的那一个最内层节点。这个表达式我在抓取嵌套列表时用得非常多，因为它能自动吃掉落一层还是落两层的结构差异。

4. 实操：给生活 APP 写一套能维护的定位表达式

4.1 先采样页面结构，再决定写什么

动手写之前，我一定先做一件事：把页面层级 dump 下来，存成文件，看清楚结构。移动端用uiautomator dump之类的工具导出 XML，Web 端直接保存 HTML 片段。这一步不要省，凭肉眼在界面上猜层级，十个里错八个。

我把导出的结构简化成下面这样（包名和 id 全部虚构）：

<hierarchy> <node class="android.widget.EditText" text="搜索商家、商品" resource-id="com.example.localapp:id/search_input" bounds="[48,240][1032,360]"/> <node class="android.widget.TextView" text="美食" resource-id="com.example.localapp:id/tab_1"/> <node class="android.widget.TextView" text="超市" resource-id="com.example.localapp:id/tab_2"/> <node class="androidx.recyclerview.widget.RecyclerView" resource-id="com.example.localapp:id/shop_list"> <node class="android.widget.FrameLayout" resource-id="com.example.localapp:id/card_8821"> <node class="android.widget.TextView" text="老张牛肉面" resource-id="com.example.localapp:id/shop_name"/> <node class="android.widget.TextView" text="4.8" resource-id="com.example.localapp:id/score"/> <node class="android.widget.TextView" text="月售 1200+" resource-id="com.example.localapp:id/sales"/> <node class="android.widget.TextView" text="免配送费" resource-id="com.example.localapp:id/tag_free_delivery"/> <node class="android.widget.TextView" text="新客立减 5 元" resource-id="com.example.localapp:id/tag_new_user"/> <node class="android.widget.Button" text="去下单" resource-id="com.example.localapp:id/btn_order"/> </node> <node class="android.widget.FrameLayout" resource-id="com.example.localapp:id/card_8822"> <node class="android.widget.TextView" text="王记砂锅粥" resource-id="com.example.localapp:id/shop_name"/> <node class="android.widget.TextView" text="4.6" resource-id="com.example.localapp:id/score"/> <node class="android.widget.TextView" text="月售 800+" resource-id="com.example.localapp:id/sales"/> <node class="android.widget.TextView" text="满 30 减 8" resource-id="com.example.localapp:id/tag_promo"/> <node class="android.widget.Button" text="去下单" resource-id="com.example.localapp:id/btn_order"/> </node> </node> </hierarchy>

注意几个细节：卡片 id 是card_加随机数字，典型的动态属性；btn_order出现了两次，属性完全一致；标签节点的 id 各不一样但文案是运营配的；月售 1200+里带空格和数字。这四点正好覆盖了前面讲的四种处境。

4.2 三段式命名：让表达式本身成为文档

在写具体表达式之前先定规范，这是我吃过亏之后养成的习惯。我用的规则叫“三段式”：范围段 → 锚点段 → 目标段，中间用/分隔，一眼能看出这段话在干什么。

举几个实际表达式：

定位搜索框输入。用contains吃前缀：

//*[contains(@resource-id,'search_input')]

定位“老张牛肉面”那张卡片里的下单按钮。锚点是店铺名，目标是按钮：

//*[@text='老张牛肉面']/ancestor::*[starts-with(@resource-id,'card_')][1]//*[@text='去下单']

定位第二张卡片。这里必须用括号，因为要全局取第二张：

(//*[starts-with(@resource-id,'card_')])[2]

定位所有带“免配送费”标签的卡片。这里用轴向上回溯再向下：

//*[@text='免配送费']/ancestor::*[starts-with(@resource-id,'card_')][1]

定位评分大于 4.7 的卡片。这是很多人不知道的用法——XPath 1.0 可以直接做数值比较，>会自动把文本转成数字：

//*[contains(@resource-id,'score') and number(@text) > 4.7]

五条表达式覆盖了列表页里 90% 的定位需求。注意它们没有一条用了完整的绝对路径，全部是靠属性锚点和轴关系推出来的。绝对路径的问题不在于写起来累，而在于页面多包一层容器它就整条失效，维护成本高到无法接受。

4.3 参数计算：bounds 中心点与屏幕比例换算

这一节讲讲参数。UI 层级里的bounds="[48,240][1032,360]"是左上角和右下角坐标，点击时需要的是中心点：

• 中心 x = (48 + 1032) / 2 = 540
• 中心 y = (240 + 360) / 2 = 300
• 宽 = 1032 - 48 = 984，高 = 360 - 240 = 120

写成通式就是 x = (x1+x2)/2，y = (y1+y2)/2。这两个公式看起来简单，但实际操作中有两个坑：一是部分框架会对 bounds 做裁剪，靠近屏幕边缘的元素坐标可能超出实际屏幕范围，点击会被系统忽略；二是不建议用 XPath 去解析 bounds 字符串，虽然理论上用substring-before和substring-after能拆出来，但嵌套太深可读性极差，交给代码用正则处理更合适。

真正需要关心的是比例换算。同一个元素在 1080 宽的屏幕上 x 是 540，到 720 宽的屏幕上应该是 360，比例是 2/3。我在做跨机型适配时会把所有坐标统一换算成屏幕宽高的百分比再做还原，而不是硬编码像素值。对于必须点固定位置的场景（比如某些没暴露 id 的自绘控件），这一层换算能把适配工作量砍掉一大半。

还有一点，浮层弹出时主页面节点通常还在树里，只是被盖住了。这时候靠文本定位可能会命中被遮挡的那一个。解决办法是在表达式里加上可见性约束，比如[@visible='true']（具体属性名看框架实现），或者干脆把搜索范围限定在浮层容器里：

//*[contains(@resource-id,'dialog') or contains(@resource-id,'popup')]//*[@text='加入购物车']

4.4 用 lxml 在本地跑通验证，别在生产环境试错

定位表达式一定先在本地验证，再往脚本里塞。我用lxml做这件事，因为它解析快、报错信息清楚，而且和浏览器里的 XPath 语法基本一致（都是 1.0）。

from lxml import etree with open('page_dump.xml', 'r', encoding='utf-8') as f: tree = etree.parse(f) def q(expr): res = tree.xpath(expr) return res if isinstance(res, list) else [res] # 1. 找出所有商家卡片 cards = q("//*[starts-with(@resource-id,'card_')]") print('卡片数量:', len(cards)) # 2. 取出每张卡片的店名和评分 for c in cards: names = c.xpath(".//*[contains(@resource-id,'shop_name')]/@text") scores = c.xpath(".//*[contains(@resource-id,'score')]/@text") print(names, scores) # 3. 评分大于 4.7 的卡片 high = q("//*[contains(@resource-id,'score') and number(@text) > 4.7]") print('高分店:', [n.get('text') for n in high]) # 4. 计算按钮中心点坐标 btn = q("//*[@text='老张牛肉面']/ancestor::*[starts-with(@resource-id,'card_')][1]//*[@text='去下单']")[0] b = btn.get('bounds') # [48,600][1032,720] import re x1, y1, x2, y2 = map(int, re.findall(r'\d+', b)) print('点击坐标:', (x1 + x2) // 2, (y1 + y2) // 2)

这段代码跑一遍，能立刻发现表达式的问题。第 2 步里注意我用的是.//开头而不是//开头——.//表示“以当前节点为根的子树内搜索”，//表示“从文档根开始搜索”。在循环里忘了加点，结果会每次都返回全文档的第一个匹配项，这是新手极其常见的错误，而且因为程序不报错、只是结果不对，排查起来很费时间。

第 4 步的re.findall(r'\d+', b)会把 bounds 里的四个数字一次抽出来，比用 XPath 的字符串函数拆要可读得多。

验证通过之后，再把表达式搬进脚本。我一般会建一个独立文件专门放定位表达式，每条都带注释说明它锚定的是什么、依赖哪些前提。APP 改版时只需要改这一个文件，而不是满脚本找字符串。

5. 失败场景与排查：那些文档里不会写的事

5.1 高频报错速查表

定位失败的原因，翻来覆去就那么几类。我把它们整理成表，出问题时按顺序对一遍，通常两三分钟能定位到根因。

5.2 三个我踩过的坑，每个都耗了半天以上

第一个坑：WebView 里的元素在原生层级里找不到。页面肉眼可见，dump 出来的 XML 里却只有一个android.webkit.WebView节点，里面空空如也。原因是 WebView 里的内容走的是另一套渲染，需要在框架里切换到 webview 上下文才能拿到 DOM。我当时的错误认知是“同一个屏幕的元素应该在同一棵树里”，这个假设在混合渲染的页面上完全不成立。判断方法很简单：dump 出来看到 WebView 节点但没有任何子节点，基本就是这个情况。

第二个坑：懒加载列表滚到一半就断。列表上显示 20 家店，实际只 dump 出 8 个节点。这不是 XPath 的问题，是列表采用了回收复用机制，屏幕外的节点根本不存在于树里。正确做法是滚动一段、取一段、再滚动，而不是指望一次性拿到全部。写循环时还要注意加“滚动前后节点集合是否变化”的判断，否则滑到底部会陷入死循环。

第三个坑：文本看起来一样，实际不一样。界面上显示“加入购物车”，代码里写[@text='加入购物车']死活匹配不到。把节点属性打印出来才发现，实际值是加入购物车，末尾带一个空格，或者中间夹了一个\u00a0。这类问题肉眼完全看不出来，只能靠repr()打印原始值对比。从那以后我处理所有文本匹配都默认套normalize-space()，宁可多一层，也不要赌文本干净。

5.3 五条让表达式活得更久的工程化经验

经验一：优先锚定“不会变的东西”。什么是不会变的？容器的层级关系、固定文案的按钮、包名前缀。什么是会变的？索引顺序、价格数字、活动标签文案。表达式的骨架应该由前者构成，后者只能做辅助过滤。我见过太多人拿价格做锚点，价格一改整个脚本报废。

经验二：宁可多写一层，不要写绝对路径。绝对路径/hierarchy/node[1]/node[2]/node[1]/node[3]是所有写法里最脆的，页面多包一层就全错。相对路径加锚点虽然长，但抗改版能力强得多。

经验三：给每条表达式配一个“自检表达式”。我习惯为关键元素同时写一条count()表达式，比如count(//*[@text='去下单'])，在脚本开头先断言数量符合预期（比如列表中就应该等于店铺数）。这样页面结构一变，脚本在定位阶段就报错，而不是跑到一半点了错误的元素、产生更难排查的数据问题。

经验四：别把 XPath 当唯一手段。如果一个元素有稳定的 id，用 id 就是比 XPath 快，没必要为了统一而统一。XPath 的定位应该留给那些“确实没有更好选择”的地方。我在实际项目里的比例大概是 id 六成、XPath 三成、其他手段一成。

经验五：性能敏感的地方要把范围收窄。移动端 XPath 定位的开销主要来自遍历，节点上千之后单次定位可能到几百毫秒。我的做法是先一次性定位到列表容器，然后在这个容器内做后续查找，把每次搜索的候选集从几千降到几十。这个改动在我的测试里能把整轮用例的执行时间压掉相当一部分，具体幅度取决于页面复杂度，但方向是确定的。

最后分享一个我一直在用的小习惯：每写一条定位表达式，都在后面加一行注释，写清楚“它依赖什么才成立”。比如//*[@text='免配送费']/ancestor::*[...]这条，注释就写“依赖：卡片容器 id 以 card_ 开头，且标签文案固定”。等哪天它失效了，看注释就知道该去检查哪个前提，不用重新分析整棵节点树。这个习惯看起来笨，但它省下来的时间，比任何技巧都实在。