浏览器自动化选择器为什么总失效？三种定位方式的稳定性对比

写浏览器自动化脚本的人大概都经历过这个循环：昨天还好好的脚本，今天一跑全是 "element not found"。

我最近连着写了几天自动化任务，选择器失效的问题反复出现。这篇文章把三种定位方式的稳定性放在一起对比，并给出一套能落地的组合策略。

## 一、先看三种定位方式

以"点击页面上的『去完成』按钮"为例，常见写法有三种。

### 1. CSS 选择器

```python

page.click("div.task-card > button.btn-primary")

```

优点是执行快、不依赖页面语义。缺点是**强耦合 DOM 结构**：前端换一套 class 命名、多包一层 div，选择器立刻失效。

### 2. 文本定位

```python

page.click("text=去完成")

```

可读性最好，写起来最直观。但它把**界面文案**变成了契约：产品把"去完成"改成"立即完成"，脚本就挂了。多语言站点上更麻烦。

### 3. 可访问性树 / 元素引用（ref）

```python

snapshot = page.accessibility_snapshot()

page.click(snapshot.ref_of("去完成"))

```

这类方案基于 ARIA 角色和名称定位，天然贴近"用户看到什么"，语义稳定性比 CSS 好。但它有一个非常具体的坑——**引用会过期**。

## 二、ref 过期是怎么回事

我实际遇到的现象是这样的：

```

点击 @e13 → 成功

观察页面 → 拿到 @e13 ~ @e80

点击 @e72 → 失败：ref @e72 unknown

```

原因在于：可访问性引用绑定的是**某一次快照时刻的节点身份**。只要页面发生重渲染（哪怕只是自动保存触发的一次局部刷新、一个 Toast 弹出、一段 loading 骨架替换），旧节点的身份就作废了，之前拿到的 ref 全部失效。

我遇到的触发源包括：

- 编辑器每 30 秒自动保存，保存完成会更新一次"数据已保存"的状态文字

- 列表异步加载，先把容器渲染出来再填内容

- 表单校验失败时插入一条错误提示，导致兄弟节点索引整体位移

**结论：ref 不是稳定的标识符，它的生命周期是"一次快照到下一次 DOM 变更"。**

### 应对办法

1. **拿 ref 后立刻用，不要缓存**。需要连点三个元素时，正确顺序是「观察 → 点第一个 → 重新观察 → 点第二个」，而不是「观察一次 → 连点三次」。

2. **失败就重新观察，不要重试同一个 ref**。重试一百次也一样，因为它指向的节点已经不存在了。

3. **优先用不随内容变化的锚点**。比如表单里带 `name` / `id` 属性的输入框，比按位置索引的 ref 稳定得多。

## 三、CSS 选择器的稳定性改造

CSS 本身不是问题，问题在于大多数人写的是「结构选择器」。改成「语义选择器」会稳很多：

```css

/* 脆弱：依赖层级和 class */

div.wrap > ul > li:nth-child(3) > a

/* 稳健：依赖业务属性 */

[data-testid="task-submit"]

[name="password"]

[aria-label="提交"]

```

只要前端愿意在关键元素上加 `data-testid`，自动化脚本的维护成本能降一个数量级。这需要前后端约定，但投入产出比很高。

## 四、文本定位的正确用法

文本定位不该用来定位「会变的东西」，但非常适合定位「不会变的东西」：

- ✅ 定位确认对话框的标题、错误提示内容、表格里的数据值

- ❌ 定位按钮文案、菜单项、状态标签

还有一个容易忽略的点：**文本定位要处理空白和换行**。页面上渲染出来的文本可能带不可见字符，精确匹配会失败。用「包含」而不是「等于」，容错率会高很多。

## 五、推荐的分层策略

实际项目里，我最后收敛成这个优先级：

```

第 1 优先：data-testid / name / aria-label 等语义属性

第 2 优先：可访问性 ref（现取现用，不缓存）

第 3 优先：稳定区域的 CSS 路径

第 4 优先：文本包含匹配（仅用于校验和兜底）

```

配套两条工程纪律：

1. **每个关键操作都校验结果**，而不是假设点击一定成功。点完按钮检查是否出现预期文案或状态变化，失败立刻报错并截图。

2. **失败时保存现场**：截图 + 当前 DOM 快照 + 控制台日志。自动化最贵的成本不是写脚本，是排查"为什么昨晚三点它失败了"。

## 六、一个具体的例子

以"提交表单"为例，脆弱写法：

```python

page.click(".form > div:nth-child(9) > button") # 全靠位置

page.wait(2000) # 靠睡等

```

稳健写法：

```python

page.click('[data-testid="form-submit"]')

# 等到"提交成功"出现，而不是盲等

page.wait_for_text("提交成功", timeout=15000)

```

后者在慢网络下不会误判，在前端改版时也不会因为多包一层 div 就挂掉。

## 七、小结

选择器失效的本质，是**你把一个会变的东西当成了不变的契约**。

三条经验：

1. **ref 是一次性的**，拿完立刻用，失败重新观察

2. **优先语义属性**（testid / name / aria-label），少用结构路径

3. **操作后必须校验结果**，别让脚本静默失败

把这三条做到，自动化脚本的"隔夜失效"能减少一大半。