管理页翻页失效后，我改成「卡片级」精确定位删除

*场景：互联网 / 后端开发，自建服务运维与后台清理。*

起因

我有一批早期传上去的测试稿要清理，全堆在某个后台列表页里

。手写点太慢，于是想用脚本驱动调试实例批量删。

设想很朴素：打开列表页 → 翻到目标页 → 逐张点删除。结果三步里两步踩空，差点酿成误删。

第一回合：翻页和搜索都不好使

先试翻页。这种列表页是单页应用，分页靠前端状态，我给 URL 加 `?page=2` 这类参数——**没用**，页面不认 URL，还是停在第一屏。

再试搜索框筛选。我定位到搜索框元素，脚本点下去、输入关键词，结果列表纹丝不动。后来才发现：**搜索框实际是隐藏元素**，脚本点了个寂寞，根本没触发真正的筛选逻辑。

两条路都堵死，我暂时退回「手动逐屏找」的思路。但这又引出第三个、也是最危险的坑。

第二回合：坐标点击差点误删

最早我图省事，按屏幕坐标去点每张卡片的「删除」按钮。问题来了：**多张卡片的删除按钮在同一屏里坐标相同**，脚本一通点，命中了好几张我根本没想删的卡片。

幸亏我之前加了个安全阀——点之前先清点「同名卡片」数量，发现数量异常就立刻停下。那一屏同名卡片偏多，安全阀触发，把误操作拦住了。**这次是真·有惊无险。**

第三回合：改成结构定位三件套

撞了坐标的坑，我彻底放弃「坐标」思路，改成靠 DOM 结构精确命中每一张卡片：

1. 从列表容器取所有卡片。实测卡片类名形如 `.cdc-2-course-panel`，一把全抓出来；

2. 每张卡片内取**标题文本 + 时间戳**，做双条件匹配——标题一致**且**时间一致才动手，避免同名误中；

3. 在卡片**内部**找操作区按钮，用 JS 直接触发点击，绕开坐标和视口滚动的问题；

4. 弹窗结构实测为 `.cdc-feedback-modal`，里面有个无障碍文案写着「确定删除」的按钮，点它确认；

5. 点完**复验**：该卡片从列表里消失才算成功，否则报警。

关键代码大概是这样

：

```javascript

// 遍历卡片，取标题+时间做双条件匹配

const cards = [...document.querySelectorAll('.cdc-2-course-panel')];

const target = cards.find(c => {

co title = c.querySelector('.title')?.innerText.trim();

const time = c.querySelector('.time')?.innerText.trim();

return title === '目标标题' && time === '目标时间';

});

// 卡片内部直接触发删除点击

target?.querySelector('.op-delete')?.click();

```

确认弹窗用轮询等它出现再点：

```javascript

function waitAndConfirm(retries = 20) {

return new Promise((resolve, reject) => {

const tick = (n) => {

const btn = document.querySelector('.cdc-feedback-modal button[aria-label="确定删除"]');

if (btn) { btn.click(); resolve(true); }

else if (n <= 0) reject('弹窗未出现');

else setTimeout(() => tick(n - 1), 300);

};

tick(retries);

});

}

```

复验消失也用轮询，确认卡片真的不在 DOM 里：

```javascript

function assertGone(title) {

const still = [...document.querySelectorAll('.cdc-2-course-panel')]

.some(c => c.querySelector('.title')?.innerText.trim() === title);

return !still; // true 表示已消失

}

```

踩到的坑

坑一：SPA 不认 URL 翻页

单页应用的分页是前端状态，改 `?page=` 没用。别跟 URL 较劲，直接操作页面状态或滚动加载。

坑二：隐藏的搜索框点了白点

元素在 DOM 里但不可见，脚本能点却没有任何效果。定位元素前先确认它真的可见、真的可交互。

坑三：坐标点击在列表里是雷

同屏多张卡片按钮坐标重合，按坐标点必误伤。**结构 + 双条件匹配 + 复验**三件套才是正解。

结果

改用卡片级定位后，6 篇目标稿全部删除并复验从列表消失。过程中还有个意外收获：因为做了卡片清点，我发现此前某次「文章还在」的判断其实是**同名卡片**造成的误判，避免了一次错误结论。

顺带确认了一个好消息

：该后台的删除是**进回收站**（可恢复），不是物理删除，风险可控。这也反过来印证了「卡片级精确定位」的价值——即便偶尔匹配偏了，最坏情况也只是进回收站，还能捞回来，不至于把数据彻底弄丢。

| 环节 | 改造前 | 改造后 |

|---|---|---|

| 翻页 | URL 参数无效 | 不依赖翻页，直接遍历 |

| 命中 | 屏幕坐标（易误删） | 标题+时间双条件匹配 |

| 确认 | 无 | 弹窗轮询 + 复验消失 |

三条经验

**第一，SPA 列表自动化放弃坐标。**

翻页、搜索、坐标点击在单页应用里都不可靠。回到 DOM 结构，用稳定的类名和文本去定位，才是稳的。坐标只是在「单张、位置固定」时看上去方便，一旦进列表批量就原形毕露。

**第二，删除要做双条件匹配 + 复验。**

只靠标题会在同名卡片上翻车，加时间双保险；点完再轮询确认卡片真的消失，才能算成功。

**第三，危险操作前加安全阀。**

我那次靠「同名卡片数异常就停」的校验拦住了误删。批量动生产数据，**先有回滚和校验，再谈效率**。

---

*本文记录的是实际调试过程，所有类名、弹窗结构与流程结论都来自当天真实测试。*

#WorkBuddy #AI办公