企业官网建设流程全解析

写完一套 Selenium 脚本，最让人抓狂的往往不是业务逻辑，而是元素定位说崩就崩。上午还好好的find_element(By.ID, "submit-btn")，下午前端同学换了个组件库，id 就变成了btn-7f3a91，脚本当场瘫掉。这种时候我一般会做一件事：把定位方式从"机器生成的属性"换成"人眼能读到的文本"。说白了，Selenium 通过文本定位并实现操作，就是让脚本像真人一样，看到页面上写着"登录""提交订单""确认删除"这几个字，就把光标挪过去、点一下、或者往里填内容。它解决的正是属性频繁变动带来的维护成本问题，适合已经会用 Selenium 基础 API、但被元素定位折磨过的测试开发和自动化从业者，也适合刚入门想把脚本写稳一点的朋友。

我见过太多团队在元素定位上反复返工，最后不得不专门拉一个人维护 locator 文件。其实文本定位这条路走顺了，脚本的存活周期能从"一次发版"延长到"半年不动"。当然它也不是银弹，后面会详细讲清楚它的代价和边界。下面我把自己这些年在这条路上的做法、踩过的坑和可以直接抄的代码，一次性摊开讲。

1. 为什么"用文本找元素"在真实项目里越来越吃香

1.1 三种属性定位集体失效的典型场景

先说清楚我们为什么要换思路。在真实项目里，有几种情况几乎一定会遇到，而它们都会让基于属性的定位失效。

第一种是现代化的前端构建链路。React、Vue 这类框架配合 CSS Modules 或 styled-components，编译出来的 class 名往往是css-1q2w3e这种哈希串。构建工具一跑，哈希就变，昨天能用的选择器今天必然报错。id 也类似，很多脚手架会给组件自动生成前缀加随机后缀的 id，人工根本没法提前猜到。

第二种是组件库带来的深层嵌套。Element UI、Ant Design 这类库把一个小小的"确定"按钮包成了div > div > button > span四层结构。你就算用 CSS 选择器一路写下去，链条又长又脆，中间任何一层加了个包装 div，整条选择器就废了。

第三种是多环境差异。测试环境的按钮 id 是btn_001，预发环境是btn_002，生产又是另一套。这种情况下维护三套选择器，纯属自找麻烦。

而在这三种场景里，唯一相对稳定的东西是什么？是用户能看见的那几个字。产品经理改文案的概率，远低于前端改 class 名的概率。所以文本定位的价值就在这儿：它锚定的是产品的语义，而不是实现的细节。

1.2 文本定位的代价与适用边界

话说回来，我不建议你把所有定位都改成文本。它有三个明确的代价，心里得有数。

第一，文案是会变的。运营做个 A/B 测试，把"立即购买"改成"马上抢购"，你的脚本就挂了。所以文本定位更适合那些产品形态已经稳定、文案经过评审冻结的模块，比如后台管理系统的固定功能按钮、导航菜单、表格操作列。

第二，文本可能重复。页面上有两个"删除"按钮——一个是删除单行，一个是批量删除。这时候单纯用//button[text()='删除']会抛ElementNotInteractableException或者干脆点错。解决办法是用find_elements拿到列表后按索引或者按父节点范围过滤，这一点在第四章会展开。

第三，XPath 文本匹配的执行效率略低于 id 和 CSS 选择器。浏览器对 id 有原生索引，而 XPath 需要遍历 DOM 树求值。不过在单个页面上，这个差异通常在毫秒级，除非你在一个上千行的大表格里循环查找，否则感受不到。

所以我的实践原则是：能用稳定的 data 属性就用属性，属性不稳的时候优先文本，文本重复的时候用"文本 + 层级范围"组合。这三层优先级排下来，脚本的健壮性会有明显提升。

2. 三种文本定位写法逐个拆解

2.1 link_text 和 partial_link_text：只对链接生效的专才

这是 Selenium 原生提供的两个文本定位方式，用法极简：

from selenium.webdriver.common.by import By # 精确匹配链接的完整可见文本 driver.find_element(By.LINK_TEXT, "忘记密码").click() # 匹配链接文本的一部分 driver.find_element(By.PARTIAL_LINK_TEXT, "忘记").click()

它们的优点是写法短、语义清楚，不需要拼 XPath。但限制也很硬：只对<a>标签生效。你拿它去找一个span或者button，必然报NoSuchElementException，不管那个元素的文字写得多明显。

另一个坑是匹配范围。LINK_TEXT比对的是链接的textContent去掉首尾空白后的值，注意是去掉首尾，中间的空格、换行、全角字符都会保留。如果链接长这样：

<a href="/reset"> 忘记<span>密码</span> </a>

那么它的完整文本是"忘记密码"，中间没有空格，LINK_TEXT可以匹配。但如果 HTML 里有换行符被渲染成空白，比如忘记 \n 密码，那LINK_TEXT就匹配不上了，因为中间冒出来一个空格。这种情况下只能用 XPath 的normalize-space，下一节会讲。

PARTIAL_LINK_TEXT稍微宽容一点，只要链接文本里包含你给的子串就命中。但宽容也是双刃剑：页面上同时存在"查看详情"和"查看详情并下载"，你写PARTIAL_LINK_TEXT="查看"，它会返回第一个匹配到的，未必是你想要的那个。所以我在实际项目里，PARTIAL_LINK_TEXT只在子串区分度足够高的时候才用。

2.2 XPath 文本定位：contains 与 normalize-space 的组合拳

XPath 才是文本定位的主力，因为它对所有标签一视同仁。下面这几种写法我在不同场景下都用过：

# 1. 精确匹配：文本必须完全等于给定值（含首尾空白） driver.find_element(By.XPATH, "//button[text()='登录']") # 2. 包含匹配：只看子串 driver.find_element(By.XPATH, "//button[contains(text(),'登录')]") # 3. 归一化后匹配：自动去掉首尾空白、合并中间连续空白 driver.find_element(By.XPATH, "//button[normalize-space(text())='登录']") # 4. 用点号匹配后代文本：跨子节点也能命中 driver.find_element(By.XPATH, "//button[contains(., '登录')]")

这里有个特别容易混淆的点，值得单独拎出来说：text()和.的区别。

text()取的是当前节点的直接文本子节点，它不会往下钻。如果按钮结构是<button><span>登</span><span>录</span></button>，那么button的直接文本子节点其实是空的，text()返回空字符串，text()='登录'匹配失败。而.表示当前节点的字符串值，它会把所有后代的文本拼起来，结果就是"登录"，能匹配成功。

这个坑我在做国际化项目时踩过——前端为了做逐字动画，把按钮文字拆成了多个 span，结果所有text()=写法的定位全部失效，换成.或者contains(string(.), ...)之后才恢复。所以我现在的习惯是：能确定文本在单个文本节点里，用text()；不确定，直接用.。反正.的容错性更高，代价只是略微慢一点点。

再说normalize-space。它做的事是：去掉字符串首尾空白，并把中间连续的空白字符（空格、Tab、换行）压缩成一个空格。这个函数对付"HTML 源码里换行缩进导致文本里混进空白"的情况特别有效。举个真实的例子：

<td class="amount"> 1,280.00 </td>

这个单元格的textContent前后各有一堆缩进空白。你写//td[text()='1,280.00']会失败，但//td[normalize-space(text())='1,280.00']稳稳命中。所以只要是从带缩进的 HTML 里取文本，我基本都会套一层normalize-space。

2.3 精确匹配和模糊匹配，到底该选哪个

这两种方式没有绝对优劣，取决于你对文本稳定性的判断。我整理了一张对照表，方便直接查：

我自己的取舍逻辑是：默认上精确加归一化，只有在文本内容会动态变化时才退到子串匹配。因为精确匹配能天然帮你排掉大部分重复元素，而子串匹配的误伤率明显更高。曾经有个项目里我偷懒用了contains(., '删除')，结果页面上有个"已删除"的筛选项也被命中，脚本点了它之后列表直接变空，排查了小半天才定位到问题。

另外一个实用技巧：如果文本本身写在value属性或者title属性里，比如按钮不给文字而是给个图标加 tooltip，那就把text()换成@title或者@aria-label：

driver.find_element(By.XPATH, "//button[@aria-label='关闭']")

现代组件库基本都会给纯图标按钮加aria-label，这算是个隐藏福利，值得优先利用。

3. 从定位到操作：一条完整的实操链路

3.1 环境准备与代码骨架

先说安装。Selenium 4.6 之后自带 Selenium Manager，也就是浏览器驱动的自动下载和版本匹配，基本不用再手动装 chromedriver 了。所以现在环境准备就一句：

pip install selenium

如果你用的是更早的版本，或者公司网络有代理限制不方便自动拉驱动，那就补一个webdriver-manager：

pip install selenium webdriver-manager

启动浏览器的骨架代码我一般这么写：

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 from selenium.webdriver.chrome.options import Options options = Options() options.add_argument("--window-size=1440,900") options.add_experimental_option("excludeSwitches", ["enable-logging"]) driver = webdriver.Chrome(options=options) driver.implicitly_wait(0) # 建议关掉隐式等待，统一用显式等待 wait = WebDriverWait(driver, 10, poll_frequency=0.3)

这里有个我坚持了很多年的习惯：把隐式等待关掉，全部用显式等待。原因在于隐式等待是全局的，它和显式等待叠加时会互相干扰，导致某些元素实际等了 20 秒才报错，排查起来一头雾水。统一用WebDriverWait之后，超时时间在每一处调用点都是显式的，读代码的人一眼就知道这里最多等多久。

3.2 封装一个"按文本点击"的通用函数

零散地写 XPath 早晚会乱，我在每个项目里都会先封装两个基础函数，一个负责按文本找元素，一个负责按文本点击：

def find_by_text(driver, wait, text, tag="*", exact=True, timeout=10): """按可见文本查元素，返回单个 WebElement""" if exact: xpath = f"//{tag}[normalize-space(.)={_quote(text)}]" else: xpath = f"//{tag}[contains(normalize-space(.), {_quote(text)})]" return wait.until(EC.presence_of_element_located((By.XPATH, xpath))) def click_by_text(driver, wait, text, tag="*", exact=True, timeout=10): """按文本找到元素并点击，点击前确保它可点""" if exact: xpath = f"//{tag}[normalize-space(.)={_quote(text)}]" else: xpath = f"//{tag}[contains(normalize-space(.), {_quote(text)})]" el = wait.until(EC.element_to_be_clickable((By.XPATH, xpath))) driver.execute_script("arguments[0].scrollIntoView({block:'center'});", el) el.click() return el

这两个函数里有三处细节值得说明。

第一处是 XPath 字符串的引号问题。中文文本里虽然不太会出现单引号，但英文文案里可能出现Don't save这种带撇号的内容，直接拼进单引号包裹的 XPath 会语法错误。所以我会写一个_quote辅助函数：如果文本里包含单引号，就改用双引号包裹；两边都有，就用 XPath 的concat()拼接。这是很多教程不会提，但线上脚本一定会碰到的细节。

第二处是element_to_be_clickable和presence_of_element_located的区别。前者要求元素既存在于 DOM 中，又是可见的、且没有被disabled属性挡住。用后者找到的元素不一定能点，尤其在按钮进页面时还处于禁用状态的情况下。

第三处是scrollIntoView。页面上有浮动表头或者固定底栏的时候，目标元素虽然存在、虽然可点，但它可能被遮挡在视口之外，直接click()会抛ElementClickInterceptedException。先滚到视口中间再点，能规避掉很大一部分这类问题。

3.3 把光标定位到文本框并输入内容

热搜里有个说法叫"将鼠标的光标定位到某个文本框中"，这个词其实要澄清一下：Selenium 并不会真的去移动操作系统的鼠标指针。它做的是通过 WebDriver 协议向浏览器发送输入事件，浏览器内部再把焦点交给目标元素。从页面效果上看，和用户用鼠标点一下输入框是一个结果，但本质不同。

所以"定位到文本框"这件事，在 Selenium 里的正确做法是：先按文本找到和输入框关联的 label 或外层容器，再用相对 XPath 定位到 input。表单场景里这个套路用得最多：

<div class="form-item"> <label>用户名</label> <input type="text" name="user" /> </div>

# 通过 label 文本找到它后面的 input xpath = "//label[normalize-space(.)='用户名']/following-sibling::input" username = wait.until(EC.element_to_be_clickable((By.XPATH, xpath))) username.click() # 让浏览器把焦点交给它 username.clear() # 清掉可能的默认值 username.send_keys("tester_01")

这里click()那一步的作用就是"把光标定位进去"。有些输入框带readonly或者被遮罩层覆盖，不先点一下，send_keys会抛ElementNotInteractableException。另外clear()在 Selenium 4 里的行为是清空value属性值，对那种受控组件（React 的受控 input）有时候清不干净，遇到这种情况的替代方案是全选删除：

from selenium.webdriver.common.keys import Keys username.send_keys(Keys.CONTROL, "a") username.send_keys(Keys.DELETE)

还有一类场景是输入框没有 label，只有placeholder。这时候可以用//input[@placeholder='请输入手机号']，虽然它不是严格意义上的文本定位，但逻辑是一样的——锚定人类可读的文字，而不是机器生成的属性。

3.4 非原生下拉框 div+ul+li 的实操拆解

这是我在面试和带新人时被问得最多的一个点，也是最容易翻车的场景。原生下拉框是<select>加<option>，Selenium 提供了Select类直接搞定：

from selenium.webdriver.support.ui import Select select = Select(driver.find_element(By.ID, "city")) select.select_by_visible_text("杭州")

但现代前端基本不用原生 select 了。原因很简单——原生 select 的样式没法自由定制。于是绝大多数组件库都用div > ul > li自己拼一个下拉框。这种结构的特点是：选项默认不在 DOM 里，或者虽然存在但被display:none隐藏，必须点击触发器之后才会渲染出来。这就意味着你不能直接去找 li，得先展开。

完整流程我通常写成四步：

# 第一步：点击触发器展开下拉框 trigger = wait.until(EC.element_to_be_clickable( (By.XPATH, "//div[contains(@class,'select-trigger')]") )) trigger.click() # 第二步：等待选项面板可见 wait.until(EC.visibility_of_element_located( (By.XPATH, "//ul[contains(@class,'select-dropdown')]") )) # 第三步：按文本找到目标选项 option = wait.until(EC.element_to_be_clickable( (By.XPATH, "//ul[contains(@class,'select-dropdown')]//li[normalize-space(.)='上海']") )) # 第四步：点击选项，并确认下拉框收起来了 option.click() wait.until(EC.invisibility_of_element_located( (By.XPATH, "//ul[contains(@class,'select-dropdown')]") ))

这四步里每一步都有存在的理由。第一步不点，第二步等什么都是白等。第二步用visibility而不是presence，是因为面板容器可能一直在 DOM 里，只是display:none，presence会立刻返回，然后在第三步点击时失败。第三步把 li 的查找范围限制在ul.select-dropdown之内，是为了避免页面上其他位置的同名文字被误命中，比如页面底部恰好有个"上海"的地名标签。第四步的确认动作是可选的，但如果脚本接下来要读下拉框上显示的选中值，这个等待能保证读到的是新值而不是旧值。

还要提一个变体：有些下拉框点开之后，选项不是 li，而是div加自定义属性，或者干脆是虚拟滚动列表，只有可视区的那几个选项真实存在于 DOM 中。虚拟滚动列表的应对办法是先在搜索框里输入关键字把目标项筛出来，再点，而不是一路滚动找。

4. 动态页面下的进阶处理思路

4.1 文本被拆散或拼接时的兜底写法

前面提过.和text()的区别，这里再往深一层。有一类页面，文本不是被拆成多个 span，而是同一个元素里混着图标文字和状态后截，比如<span><i class="icon"></i>待审核</span>。normalize-space(.)得到的结果就是"待审核"，因为图标元素本身没有文本。这种情况没问题。

但如果结构变成<span><i></i>待审核（3 天）</span>，你想匹配的语义是"待审核"，后面那个天数会随状态变。这时候精确匹配就废了，得退到contains：

xpath = "//span[contains(normalize-space(.), '待审核')]"

再狠一点的场景，文本里混了零宽字符或者不换行空格（ ）。 在 HTML 里表现为\xa0，它不属于普通空格，normalize-space会把它当成空白处理吗？严格来说，XPath 的空白定义包含空格、Tab、换行、回车，\xa0在部分浏览器的实现里也算，但并不保证一致。我遇到过一次很诡异的匹配失败，最后是把目标元素的textContent打印出来，用repr()一照才发现藏着\xa0。解决办法是用translate()把它先替换掉：

xpath = ("//span[normalize-space(translate(., '\xa0', ' '))='提交订单']")

这个写法看着啰嗦，但在处理老系统的时候是真管用。

4.2 文案会变的时候，怎么让定位活下来

多语言站点或者文案经常调整的模块，单条文本定位就是个定时炸弹。我的做法是维护一个"文本候选池"，按优先级依次尝试：

def click_by_any_text(driver, wait, texts, tag="button", timeout=8): for t in texts: try: xpath = f"//{tag}[normalize-space(.)={_quote(t)}]" el = WebDriverWait(driver, timeout).until( EC.element_to_be_clickable((By.XPATH, xpath)) ) el.click() return t except Exception: continue raise AssertionError(f"候选项全部未命中: {texts}") # 调用：新老文案都兜住 click_by_any_text(driver, wait, ["立即购买", "马上抢购", "去下单"])

注意这里每次尝试都重新创建了WebDriverWait，而不是复用同一个。原因是复用的时候总超时是共享的，第一个候选就吃掉全部时间，后面几个没机会试。分开创建之后，每个候选有独立的 8 秒窗口，整体最长等待时间会变成候选数乘以超时时间，所以候选项别放太多，三到五个足够。

另外一个值得提的思路是双通道定位：主通道用文本，兜底通道用>def robust_click(driver, wait, text, testid=None): try: return click_by_text(driver, wait, text) except Exception: if testid: el = wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, f"[data-testid='{testid}']"))) el.click() return el raise

这种写法的好处是，即使文案改了、脚本也不会立刻失效，而是走备用路径继续跑。等哪天有空了再回头更新文案池。

4.3 页面元素枚举与"只存定位元数据"

当页面上一批元素的文本遵循同一规律时，比如一个表格的每一行末尾都有一个"查看"链接，逐个写死 XPath 就太笨了。这时候用find_elements做枚举更合适：

rows = driver.find_elements(By.XPATH, "//table[@id='order']//tbody/tr") for i, row in enumerate(rows): # 取出这一行里的状态文本 status = row.find_element(By.XPATH, ".//td[contains(@class,'status')]").text.strip() if status == "待发货": # 只在满足条件的行里点按钮，避免误点其他行 row.find_element(By.XPATH, ".//a[normalize-space(.)='发货']").click()

这里有个容易忽略的细节：行内查找的 XPath 必须以.开头，比如.//td。不加那个点，//td会从整个文档根开始找，你以为是限定在行内，实际上找的是全页面第一个匹配的 td。这个坑我见过至少三个同事踩过，症状是"明明只该点第二行，结果每次都点第一行"。

再说一个概念：枚举得到的是元素引用，不是定位信息。find_elements返回的WebElement对象内部持有的是当前页面上下文的引用。一旦页面发生跳转、局部刷新或者 SPA 的视图切换，这些引用就全部失效了，再调用它们的.text或者.click()会抛StaleElementReferenceException。

所以在需要跨多次操作、跨页面复用的场景下，正确的做法是只存储定位元数据，需要的时候现查。所谓定位元数据，就是(By.XPATH, xpath_string)这样的元组，而不是元素对象本身：

# 不好的做法：缓存元素对象 elements_cache = {row.text: row for row in rows} # 页面一刷新就全废 # 好的做法：缓存定位元数据 locator_cache = {} for i, row in enumerate(rows): locator_cache[row.find_element(By.XPATH, ".//td[1]").text] = ( By.XPATH, f"//table[@id='order']//tbody/tr[{i + 1}]//a[normalize-space(.)='发货']" ) # 要用的时候现场查 by, value = locator_cache["订单号8891"] wait.until(EC.element_to_be_clickable((by, value))).click()

这个习惯一旦养成，脚本的稳定性会有质的提升，因为它天然规避了元素过期的问题，也顺手把"页面刷新了怎么办"这个隐患解决了。

5. 常见报错与排查速查表

5.1 NoSuchElementException 的几种常见成因

报"找不到元素"的时候，绝大多数情况不是定位写错了，而是时机或者上下文不对。我按出现频率列一下。

第一，元素还没渲染出来。尤其是 SPA 页面，路由切换之后首屏是骨架屏，真实内容要等接口返回才挂上去。这种情况下把WebDriverWait加上基本就解决了。如果加了等待还是找不到，那说明不是时机问题。

第二，元素在 iframe 里。这是最典型的"明明能在浏览器里看到，脚本就是找不到"。解决方法是切进去：

wait.until(EC.frame_to_be_available_and_switch_to_it((By.ID, "pay-frame"))) # 操作完之后记得切回来 driver.switch_to.default_content()

很多人只记得切进去，忘了切回来，导致后面所有定位都失败，查半天查不出来。我现在写这类代码时会在切进去的下一行就写好切回来的注释，提醒自己。

第三，文本里混了空白或者特殊字符。前面讲过normalize-space和translate的用法，这里不重复。排查方法很简单，先用 XPath 定位到元素，把.get_attribute("textContent")打印出来用repr()看一下，真相立刻就出来了。

第四，点击触发器之后元素才出现，但代码没等。下拉框、弹窗、折叠面板都属于这类。解决办法是把等待放在"点击触发器"的后面，而不是前面。

第五，元素在 Shadow DOM 里。Web Components 越来越常见，Shadow DOM 内部的节点对普通 XPath 是不可见的。Selenium 4 提供了shadow_root属性来穿透：

host = driver.find_element(By.CSS_SELECTOR, "my-component") shadow = host.shadow_root shadow.find_element(By.CSS_SELECTOR, "button").click()

不过要注意，shadow_root只能穿透一层，嵌套 shadow DOM 需要逐层往下钻。

第六，被滚动容器限制。元素在滚动区域下方，虽然 DOM 里存在但因为滚动容器的 overflow 属性，它不占视口。这时候需要先滚到它，或者直接对它做execute_script滚动。判断依据是浏览器里的开发者工具可以找到它，但 Selenium 报元素不可交互。

5.2 点击了但没反应，或者点了别的元素

这类问题比找不到更麻烦，因为不报错，脚本继续往下跑，最后在断言的时候才炸，此时现场早就没了。

最常见的原因是元素被遮挡。页面上有固定的导航栏或者浮动的客服按钮，正好盖在目标元素上方。Selenium 的click()会先计算目标元素的中心坐标，然后在那儿派发点击事件，如果那个坐标被别的元素占了，浏览器收到事件的就是遮挡物。这也就是为什么加一行scrollIntoView往往能解决问题——把元素滚到视口中央，浮层就盖不到了。

第二个原因是动画没结束。按钮点下去之后有个 300 毫秒的缩放动画，元素在动画中位置一直在变，click()算出来的坐标可能是动画中间态的。这类情况我会在点击后加一个短等待：

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 等元素位置稳定 wait.until(lambda d: d.find_element(By.XPATH, xpath).is_displayed()) # 或者等 loading 遮罩消失 wait.until(EC.invisibility_of_element_located((By.CSS_SELECTOR, ".loading-mask")))

第三个原因是匹配到多个元素。find_element在多匹配时返回第一个，这个"第一个"是按 DOM 顺序，不是按视觉顺序。如果页面上有两个同名按钮，一个在隐藏的弹窗里，一个在主界面上，find_element很可能会返回弹窗里那个隐藏的。解决办法是把查找范围收窄到某个稳定的容器内：

xpath = "//div[@id='main-content']//button[normalize-space(.)='提交']"

养成"先框定范围、再按文本定位"的习惯，能挡掉相当多的误命中。

5.3 问题排查速查表

这张表我一般是直接贴在内部分享文档里的，新人照着查，能解决八成的定位问题。

6. 几个我踩过之后才记住的实操细节

6.1 空格、全角半角、不可见字符

中文页面里的空白字符是个大坑，值得单独说。除了前面提到的 ，还有几个常见的：

一个是全角空格（\u3000），运营在后台配置文案时输入法没切回来，就会打出来。它在视觉上和普通空格几乎一样，肉眼根本看不出来，但字符串比较一定失败。处理办法是把它也纳入translate：

xpath = "//span[normalize-space(translate(., ' \xa0', ' '))='限时抢购']"

另一个是 BOM 或者零宽字符（\u200b），常见于从 Excel 或者文档里复制过来的文案。这类字符在页面上完全不可见，但会让精确匹配失效。排查的通用手段还是那句：打印repr()，然后对着\u开头的转义码看。

还有一个不那么常见但确实存在的场景：数字里的千分位符号。有系统用半角逗号1,280，有的用全角逗号1，280，还有的用空格1 280。如果你的定位要落在金额上，最好别用完整金额文本，而是只用金额前面的固定前缀来匹配，比如contains(., '订单金额')，然后从元素里读值再自己解析。

6.2 把定位元数据集中放，别散落在代码里

这一条是我这几年最受益的工程习惯。刚开始写脚本的时候，我习惯把 XPath 内联在调用处，一个文件里散落着几十条 XPath 字符串。等到前端改一次版，我要靠全局搜索去一条条改，改漏一条就留个雷。

后来我改成统一放到一个模块里：

# locators.py class OrderPageLocators: SEARCH_INPUT = (By.XPATH, "//label[normalize-space(.)='订单号']/following-sibling::input") SUBMIT_BTN = (By.XPATH, "//button[normalize-space(.)='查询']") EXPORT_BTN = (By.XPATH, "//button[contains(normalize-space(.), '导出')]") # test_order.py from locators import OrderPageLocators as L wait.until(EC.element_to_be_clickable(L.SUBMIT_BTN)).click()

这样改版的时候只需要动一个文件，而且能一眼看出全站用了多少条基于文本的定位，便于评估风险。再进一步，可以给每个定位加个备注，写清楚这条 XPath 是基于哪个版本的文案，万一文案改了，回溯起来也快。

6.3 我的稳定性优先级排序

最后说说我在实际项目里怎么排定位方式的优先级，这个顺序帮我把脚本的月度维护工作量压到了很低。

第一优先是>