在数据管理和后台系统中，表格是记录展示的核心形式。每一行代表一条用户数据，操作列通常包含编辑、删除等按钮。当自动化脚本需要删除某个用户时，邮箱地址是最可靠的定位依据，因为它具有唯一性。但真正实现时，问题往往比预想的复杂：邮箱文本可能同时出现在多个列、筛选条件、隐藏节点或分页区域中。如果只是找到页面上的删除按钮并点击，很可能误删其他行或者直接报错。本文围绕“先锁定目标行，再定位操作按钮”的思路，说明如何通过邮箱精确定位并点击对应的删除按钮。
一、为什么直接通过邮箱文本找删除按钮容易失败
很多自动化测试脚本会先通过XPath中的text()函数查找邮箱文本，然后再尝试点击相邻的删除按钮。这种做法在简单页面里确实有效，但在真实项目中经常出现三类问题。第一，邮箱文本可能匹配到多个元素。比如页面顶部有一个全局搜索框，输入框内已经遗留了邮箱关键字；或者表格上方有筛选条件显示当前邮箱；此时text()返回的第一个节点不一定是目标行。第二，删除按钮并不一定是邮箱元素的相邻兄弟节点。通常邮箱位于某个<td>中，而删除按钮位于同一行的另一个<td>内，二者之间隔着多个标签层级。如果依赖固定的层级关系或绝对索引，列顺序一旦调整，脚本就会失效。第三，表格数据往往通过AJAX异步加载，元素尚未渲染完时执行点击会抛出NoSuchElementException或StaleElementReferenceException。把这些风险点逐一解决，才能设计出稳定的定位方案。
更稳妥的策略是：先用邮箱锁定包含它的<tr>行元素，再在这个行的作用域内查找删除按钮。这样做有两个好处。其一，即使邮箱文本在其他区域出现多次，只要表格中的那一行先被精确定位，查找范围就缩小到了正确的用户记录。其二，删除按钮的查找不再依赖与邮箱的绝对位置关系，只要它位于同一行内，无论列如何调整都能命中。下面的示例将围绕这一原则展开。
二、用XPath定位邮箱所在行并点击删除按钮
XPath天生适合处理表格层级关系。核心表达式可以分为两步：第一步找到包含指定邮箱的<tr>，第二步在行内寻找删除按钮。下面是一个基于Selenium WebDriver的Python实现。
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
def click_delete_by_email(driver, email, button_text="删除"):
wait = WebDriverWait(driver, 10)
# 先等待包含目标邮箱的行出现
row_xpath = f"//tr[td[contains(normalize-space(.), '{email}')]]"
row = wait.until(EC.presence_of_element_located((By.XPATH, row_xpath)))
# 再在行内定位删除按钮
delete_btn = row.find_element(By.XPATH, f".//button[contains(., '{button_text}')]")
delete_btn.click()
这段代码没有直接全局查找删除按钮，而是先用//tr[td[contains(normalize-space(.), '{email}')]]锁定行。使用normalize-space()可以去除单元格文本中的多余空白，避免因为前端模板换行导致匹配失败。找到行元素后，再通过相对XPath.//button[contains(., '删除')]在行内查找按钮。这里的点号表示从当前行节点开始搜索，而不是整个文档。
如果删除按钮没有文字，而是一个图标，可以改用class、aria-label或data属性定位。例如.//*[contains(@class, 'btn-delete')]，或者.//button[@aria-label='删除']。表格中按钮的class往往带有命名空间或哈希后缀，使用contains比完全匹配更灵活。需要注意的是，当邮箱地址本身包含单引号时，直接拼接XPath会造成语法错误。此时可以优先使用CSS选择器，或者在拼接前对邮箱变量进行转义处理。另一个常见问题是邮箱列中除了地址外还包含头像、姓名等子元素，contains仍然能匹配，但如果要求完全相等，应使用归一化后的文本比较。
三、用Playwright与CSS选择器实现更稳定的行定位
相比Selenium，Playwright提供了更现代的定位方式，自动等待和过滤能力更强。Playwright的locator支持通过行文本直接筛选，非常适合“先锁定行再点按钮”的场景。下面是一个同步API示例。
from playwright.sync_api import sync_playwright
def click_delete_by_email(page, email):
# 根据行文本定位包含邮箱的行
row = page.get_by_role("row", name=email)
# 在行内定位删除按钮
row.get_by_role("button", name="删除").click()
get_by_role("row", name=email)会根据行的可访问名称进行匹配。行的可访问名称由它的所有文本内容拼接而成，因此只要邮箱地址在行中出现，就能定位到该行。相比XPath的字符串拼接，这种方式不需要担心引号转义问题。如果页面中同一个邮箱在普通表格和隐藏的移动端表格中各出现一次，get_by_role可能返回多个行。此时可以结合filter或first进一步缩小范围，例如page.get_by_role("row").filter(has_text=email).first。不过应当优先确认目标容器，再在容器内查找，而不是盲目取第一个。
如果团队仍倾向于使用CSS选择器，Playwright也支持:has()与:text()伪类。例如page.locator("tr:has(td:text('user@ippipp.com'))")可以定位包含特定文本的表格行。之后再用row.locator("button:has-text('删除')").click()点击操作按钮。这种方式语义清晰，但要求浏览器版本较新。无论使用XPath还是CSS选择器，核心都是把行和按钮的定位分离，避免使用绝对索引。
四、处理动态加载、分页和重复匹配的进阶思路
真实的业务表格往往不是一次性渲染完成的。分页、滚动加载、搜索过滤都会影响元素的可定位性。如果目标邮箱不在当前页，直接查找注定失败。此时应该先检查当前页是否存在目标行，如果不存在，可以调用搜索框输入邮箱或跳转到对应分页，然后再定位。封装删除函数时，建议把搜索和定位拆开，例如先执行搜索，再等待行出现，最后点击删除按钮。
重复匹配是另一个需要重视的问题。有的系统会在表格上方显示高级筛选摘要，或者在隐藏的移动端版本中保留同一行数据。当定位器返回多个行时，需要增加过滤条件。常见做法是使用可见性过滤。在XPath中可以加上[not(contains(@style,'display:none'))]，在Playwright中则可以调用visible过滤。如果页面同时存在弹窗和背景表格，还需要先关闭弹窗或明确指定主体表格的容器。将定位逻辑限定在某个<table>容器内，是减少重复匹配的有效手段。
最后给出一个较完整的Selenium封装思路：函数接收邮箱、删除按钮文本、表格容器定位器三个参数。先等待容器加载，再在容器内查找行和按钮；如果找不到，可以触发搜索或抛出明确异常。这样脚本的可维护性会大大提升。无论底层使用Selenium、Playwright还是Cypress，只要坚持“行作用域内查找操作按钮”的原则，就能显著降低定位失败的概率。