Selenium 是 Web自动化测试 里最经典的一把“手”：它让你用 Python 代码驱动浏览器，模拟点击、输入、翻页、下载，做到像真人一样操作浏览器。如果你已经跟着 Python 路线图走到第 56 天，对 requests、类、装饰器这些都不陌生了，那今天这套东西，正好是检验基本功的试金石。这篇文章不打算把官方文档复述一遍，我会把实际项目里把 Selenium 从“能跑”调到“稳定好用”的经验拆开讲，核心围绕元素定位、等待策略、动作链、反识别细节，以及一堆只有踩过坑才记得住的排查技巧。
1. 为什么偏偏是 Selenium：它能“像真人”的本质是什么
1.1 Selenium 在 Python 技术栈里的定位
Selenium 最早是浏览器自动化测试框架，后来被大量用于重复任务自动化、定时巡检、数据采集等场景。Python 只是它支持的其中一种语言，但 Python 生态成熟，很多人用起来最顺手。它的核心原理是通过 WebDriver 协议去驱动你本机安装的浏览器，浏览器界面是真的被打开了，页面里的渲染、动画、异步请求、DOM 事件，都是真实发生的。
这就和直接用 requests 发请求有本质区别。requests 是站在“门外”模仿 HTTP 报文，服务器返回什么 HTML、JS 脚本，它拿到的是静态文本；Selenium 是“进门坐下了”，浏览器执行完 JavaScript、渲染完布局之后再告诉你“页面长这样”。所以遇到前端渲染很重的页面，比如日历组件、图表报表、登录后动态生成的菜单，用 requests 解析可能很头疼，Selenium 反而轻松。
后面的章节会频繁提到“稳定”这个词。很多人觉得 Selenium 慢、脆弱，其实不是工具的问题，而是没有理解浏览器的生命周期和渲染时序，导致脚本里到处是强睡、固定等待。这种东西在网速稳定的环境跑得通，一换网络、一换浏览器版本，马上就给你颜色看。
1.2 “像真人”的关键到底是什么
“像真人一样操作浏览器”这句话，说起来轻松，实际上有两层意思。
第一层是行为层面：真人操作浏览器，会触发完整的鼠标事件、键盘事件、焦点变化和滚动。Selenium 的click、send_keys、ActionChains都是经过 WebDriver 协议向浏览器派发真实事件，所以页面上的onclick、onchange、mousedown、mouseup、blur这些监听器都会被触到。这也是为什么很多前端交互组件，比如下拉框、上传控件、日期选择器，用模拟 HTTP 方式很难驱动，但 Selenium 可以做到。
第二层是结果层面：真人操作之后，页面会异步加载数据、跳转路由、弹提示框，自动化脚本也必须等这些“后续结果”出现才能继续下一步。这里最忌的就是不管三七二十一sleep(5)。后面第 4 章会专门展开等待策略，因为 90% 的自动化失败都出在“没等到该等的东西”。
把这两层做好，脚本才真正接近“像真人”。但也要清醒，这并不等于完全不会被识别，第 5 章里我会单独讲身份特征的问题。
1.3 完全新手要不要担心环境问题
很多人一听 Selenium，第一反应就是驱动要怎么配、浏览器会不会报错、无头模式是什么。其实环境准备没有想象中复杂，核心就是三件事：Python 环境、浏览器本体、浏览器驱动。
浏览器驱动必须和浏览器版本匹配，否则打开就报 “session not created” 或者版本不匹配错误。早期做法是去浏览器的驱动下载页面手动找对应版本的驱动，再放到系统 PATH 里，麻烦不说，浏览器一升级就崩。现在我更推荐在项目里用驱动管理库自动处理，具体在第 2 章演示。
如果你之前完全没碰过浏览器自动化，建议先把代码跑通，看见浏览器真的被打开，再做后面的优化。第一次成功打开浏览器，其实你已经走完最难的心理门槛了。
2. 环境搭建：让代码第一次打开你的浏览器
2.1 用 pip 安装 selenium 和驱动管理库
先给出一份可以直接执行的安装命令：
pip install selenium pip install webdriver-managerselenium是核心库，webdriver-manager负责帮你下载和管理浏览器驱动。很多时候你只需要写代码，不需要关心驱动具体放在哪里。它会自动找到你本机浏览器的版本，然后从对应渠道下载匹配的驱动，并且缓存到本地，下次启动会更快。
安装完成之后，写下面这个最小脚本，应该可以弹出一个真实的浏览器窗口，并且打印出页面的标题：
from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager service = Service(ChromeDriverManager().install()) driver = webdriver.Chrome(service=service) driver.get("https://example.com") print(driver.title) # 如果打开成功，会打印出这个页面的标题 driver.quit()这里我默认你用的是 Chrome 浏览器。如果你平时用 Firefox，思路完全一样，只要换成对应的驱动管理类就行。关键是理解Service负责驱动启动，webdriver.Chrome负责启动浏览器实例。
2.2 驱动管理方式对比：为什么不要手动下载
我在刚接触 Selenium 的时候也手动下载过驱动，后来换了一台电脑，完全不知道要复制配套文件，脚本瞬间报废。手动下载的主要问题有三个：
- 浏览器版本频繁升级，驱动匹配容易出错；
- 团队协作时，每个人机器上的驱动都可能有差异；
- 服务器环境没有图形界面时，驱动路径配置更麻烦。
用webdriver-manager之后，这些问题基本消失。它会在运行时检测浏览器主版本，自动拉取对应驱动。虽然不是绝对完美，偶尔也会因为网络原因拉取失败，但比手动管理省心太多。如果遇到拉取失败，可以直接手动下载驱动放到项目目录，再用Service(executable_path="./chromedriver")指向本地文件，两种方式都支持。
2.3 第一份稳定可复用的浏览器配置
打开浏览器只是开始，真实项目里你还需要关闭不必要的安全限制、控制日志输出、设置无头模式等。下面这份配置是我在实际工作中常用的基础模板：
from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager options = Options() # 减少自动化被识别的特征 options.add_argument("--disable-blink-features=AutomationControlled") # 服务器环境通常需要这两个参数 options.add_argument("--no-sandbox") options.add_argument("--disable-dev-shm-usage") # 如果不想弹出浏览器窗口，就取消注释这一行 # options.add_argument("--headless=new") driver = webdriver.Chrome( service=Service(ChromeDriverManager().install()), options=options )这里我要提醒一个实操细节：无头模式虽然很适合挂在服务器上跑，但调试阶段不要开。无头模式下浏览器窗口不显示，你很难判断页面实际长什么样，出问题只能看截图，效率会低很多。稳妥做法是：先有头调试，脚本稳定之后再切无头。
--no-sandbox和--disable-dev-shm-usage是容器或受控环境里常见的参数，本地开发不加上也能跑，但提前加上可以避免换环境时莫名其妙报错。这些参数不是越多越好，按需添加，保持可读性。
3. 元素定位基本功：让代码找到页面上的按钮、输入框和菜单
3.1 八大定位方式怎么选：从 ID 到 XPath
Selenium 的find_element系列支持八种定位方式，但实际高频使用的没有那么多。我建议记住一套优先级判断逻辑，而不是死记硬背：
| 定位方式 | 常用场景 | 容易踩的坑 |
|---|---|---|
| ID | 页面里有明确且唯一的 id 属性 | 动态生成 ID 会变，不能写死 |
| Name | 表单输入框经常有 name 属性 | 页面上可能有多个同名元素 |
| CSS Selector | 属性组合、层级定位，灵活高效 | 需要掌握 CSS 选择器语法 |
| XPath | 按文本内容、复杂父子关系定位 | 写得太长容易脆弱，尽量用相对路径 |
| Link Text | a标签链接文本 | 只适用于链接，不能用于按钮 |
| Class Name | 按样式类批量定位 | class 名可能包含空格，要留意 |
| Tag Name | 统计某类标签数量 | 匹配范围太大，慎用 |
| Partial Link Text | 链接文本包含某个关键字 | 可能出现多个匹配 |
实际写代码时，最常见的写法就这几种：
from selenium.webdriver.common.by import By driver.find_element(By.ID, "username").send_keys("test_user") driver.find_element(By.CSS_SELECTOR, "input[name='password']").send_keys("123456") driver.find_element(By.XPATH, "//button[contains(text(),'登录')]").click()使用 XPath 定位按钮文本时，我强烈建议用contains(text(), '登录')，而不是直接text()='登录'。因为真实页面里按钮文字前后可能有空格、换行、图标文字混排，直接等号匹配很容易失败。contains是“包含”语义，容错率更高。
3.2 iframe 里的元素为什么死活找不到
刚做 Selenium 时最容易卡住的问题之一：页面里明明有登录按钮，但代码一直报NoSuchElementException。这时候首先要看一下，按钮是不是在一个 iframe 里。
iframe 可以理解成页面里嵌套的另一个文档。你当前默认是在最外层文档找元素，所以 iframe 内部的东西对你来说是“另一个世界”。必须先切换进去，才能操作里面的元素：
iframe_element = driver.find_element(By.TAG_NAME, "iframe") driver.switch_to.frame(iframe_element) # 现在可以操作 iframe 内部的元素了 driver.find_element(By.ID, "captcha_input").send_keys("1234") driver.find_element(By.ID, "confirm_btn").click() # 操作完要切回主文档 driver.switch_to.default_content()这里最重要的习惯是：切换进 iframe 后，不需要了下一次还要继续操作页面外层元素时，必须切回来。很多人忽略这一步，导致后续定位全部失效，还以为是浏览器出了问题。另一种定位 iframe 的方式是通过 id 或 name 直接切，比如driver.switch_to.frame("login_frame")，如果你确定 iframe 有 id，也可以用这种方式。
3.3 动态元素与 XPath 优化实战技巧
真实业务系统里，很多元素 id 是动态的，比如item_12345、row_8382，每次刷新都会变。这种 id 如果写进定位表达式，脚本第二次跑就废了。解决办法是寻找稳定不变的父节点，再通过层级往下找。
举例：一个订单列表，每行都有删除按钮，id 形如delete_20250101_842。用//tr[@class='order-row']//button[contains(text(),'删除')]去定位，比写死 id 稳健得多。即使是数据变化，只要 DOM 结构不变，就能定位到。
再补充一个 XPath 技巧：尽量用相对路径，不要从根节点开始写一长串绝对路径。绝对路径一旦页面微调，比如中间加了一层<div>，整个脚本就会崩塌。相对路径配合contains、following-sibling、preceding-sibling这些轴操作，可以处理很多复杂场景。
4. 等待机制是自动化稳定的分水岭：三种方式与超时调试
4.1 强制等待、隐式等待、显式等待怎么选
页面加载是异步的，不是你get()打开 URL 时所有元素就都准备好了。有些按钮点击之后要发请求、等响应、再渲染结果。如果你不管这个过程，立刻去找下一个元素，大概率会失败。
三种等待方式本质上是三种哲学：
- 强制等待
time.sleep(3)：不管页面状态如何，固定睡 3 秒。优点是简单粗暴，缺点是网络快时浪费时间，网络慢时依然不够。 - 隐式等待
driver.implicitly_wait(10)：告诉浏览器“在 find 元素时最多等 10 秒”。它能解决元素还没出现的问题，但解决不了元素出现却不可见、不可点击、值还没变化这类问题。 - 显式等待
WebDriverWait+expected_conditions：针对某个具体条件等待，比如“这个按钮可点击了”“这个元素里出现了指定文本”“当前 URL 变了”。这是最可靠的方式。
我的项目里基本只用显式等待，隐式等待甚至会带来麻烦：如果你设置了隐式等待 10 秒，那么某些你希望快速失败的查找也会被拖慢到 10 秒，调试时会非常难受。
4.2 Expected Conditions：不要只等元素存在
很多教程会教你用presence_of_element_located，意思是元素出现在 DOM 里。但这还不够。元素出现在 DOM 里，不代表它可见、可点击、没有被其他浮层遮挡。
我最常用的是：
from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By wait = WebDriverWait(driver, 10) login_btn = wait.until( EC.element_to_be_clickable((By.XPATH, "//button[contains(text(),'登录')]")) ) login_btn.click()element_to_be_clickable会同时检查元素可见且可用。对于输入框，我会用visibility_of_element_located而不是presence_of_element_located，确保输入框真的显示在页面上再输入。
还有一个容易被忽略的条件：text_to_be_present_in_element。比如点击查询按钮之后，列表区域可能出现“共 20 条记录”，你可以等待这个文本出现，再继续下一步。这比单纯等待元素存在更能代表“数据加载完成”。
wait.until( EC.text_to_be_present_in_element((By.ID, "result_total"), "条") )4.3 TimeoutException 超时后先别着急改代码
当脚本报TimeoutException，我建议第一件事不是调大等待时间，而是“把现场抓下来”。页面在那一刻到底是什么状态，截图和 HTML 快照能给出准确答案。
推荐封装一个通用的等待点击函数，超时时自动截图和保存页面源码：
def wait_and_click(driver, by, locator, timeout=10): try: element = WebDriverWait(driver, timeout).until( EC.element_to_be_clickable((by, locator)) ) element.click() except Exception: driver.save_screenshot("debug.png") with open("debug.html", "w", encoding="utf-8") as f: f.write(driver.page_source) raise调试时看到截图里元素还在转圈，基本就是异步请求没有完成；看到元素被弹窗遮住，说明要先关闭弹窗；看到页面跳到了别处，说明你的输入或点击触发了一个意外行为。每一次超时都不是随机事件，它一定在告诉你页面时序和你想的不一样。
5. 键盘鼠标动作链：模拟真人操作的核心手法
5.1 点击、输入、键盘组合键的实操细节
普通的点击和输入看上去很简单，但真实页面上常有几个坑。
第一，send_keys输入中文时不需要特殊处理，直接把中文字符串传进去就行。但如果输入框有输入法干扰，或者页面限制输入格式，先点击输入框再输入会稳妥一些。
第二，clear()清空输入框在某些自定义组件上不生效。更可靠的方式是选中全部后删除：
from selenium.webdriver.common.keys import Keys input_box = driver.find_element(By.ID, "keyword") input_box.click() input_box.send_keys(Keys.CONTROL, "a") input_box.send_keys(Keys.DELETE)第三，键盘组合键在提交表单、翻页、关闭弹窗时非常好用。比如文本框输入完直接回车提交：
input_box.send_keys("Python自动化") input_box.send_keys(Keys.ENTER)这里要注意Keys.CONTROL, "a"的写法，很多人会写成send_keys("ctrl+a")，那是错误格式。Selenium 的Keys类专门定义了这些按键常量，组合键就是依次传入按住的键和实际按键，按完会自动释放。
5.2 ActionChains：拖拽、悬浮、右键菜单
ActionChains是模拟真人操作的一把利器，适合那些不是简单点击和输入能覆盖的场景。比如一个电商页面的二级菜单，鼠标必须悬停在父菜单上，子菜单才会浮现，然后才能点击子菜单项。用普通click是点不出子菜单的，需要先move_to_element：
from selenium.webdriver.common.action_chains import ActionChains parent_menu = driver.find_element(By.CLASS_NAME, "nav-item") ActionChains(driver).move_to_element(parent_menu).perform() child_menu = driver.find_element(By.XPATH, "//a[contains(text(),'子菜单')]") child_menu.click()拖拽排序、滑块验证、右键菜单也是一样：
actions = ActionChains(driver) # 右键点击 actions.context_click(target_element).perform() # 拖拽：把 source 拖到 target actions.click_and_hold(source) actions.move_to_element(target) actions.release() actions.perform()千万记得：ActionChains 的每一个动作只是“安排”好了，不会立刻执行，必须调用perform()才会真正触发。如果你发现动作没有生效，先检查是不是漏了perform()。
5.3 滚动页面与 JS 注入的边界场景
有些页面是滚动加载模式，你必须滚到底部，新数据才会加载出来。直接用window.scrollTo是最快的：
driver.execute_script("window.scrollTo(0, document.body.scrollHeight)")如果你的目标是模仿真人，每次都瞬间滚到底部反而“太假了”。更自然一点的做法是用ActionChains模拟滚动，或者按 PageDown 键分几次往下翻。不过在自动化任务里，效率和真实感要平衡，我会优先保证执行效率，只在目标系统对行为速度敏感时才刻意放慢。
execute_script也可以用来修改元素属性、读取 value 值、强制点击隐藏元素。但我不建议所有操作都用 JS 绕过去，因为那等于丢弃了 Selenium“模拟真实用户事件”的核心价值。只有当普通点击遇到遮罩层或元素不可见时，才考虑用 JS 作为兜底方案。
5.4 防被识别：如何让自动化环境更像普通用户
现在很多网页会检查navigator.webdriver这个标记。默认情况下，用 Selenium 控制的浏览器这个值会是true，这是最大的身份暴露点。常见优化做法是在启动参数里关闭自动化控制特征，并通过 CDP 脚本覆盖webdriver属性：
options.add_argument("--disable-blink-features=AutomationControlled") driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", { "source": "Object.defineProperty(navigator, 'webdriver', {get: () => undefined})" })也可以给自己的浏览器配置一个贴近真实用户的用户代理。这里要强调：这类操作的目的，是让自动化测试环境更接近普通用户，避免正常的业务风控把测试流量误伤。无论做什么自动化，都必须遵守目标网站的使用条款，只做自己有权操作或已获授权的任务。
我也踩过很深的坑：做了隐藏特征，结果还是被识别。原因往往不是指纹，而是行为太快、太规律。真人操作不可能每次间隔固定 0.5 秒，不可能把鼠标从 A 点直线瞬移到 B 点，不可能每步都零失误。如果脚本面对严格的风控系统，除了优化特征，还要适当加入随机延迟和拟人化的鼠标移动轨迹。
6. 实战环节：模拟一次完整的登录、查询、下载流程
6.1 场景设计与页面分析
我拿一个内部模拟项目举例：某后台系统。操作人输入账号密码登录，登录后进入订单查询页，按日期范围查询，等待结果列表出现，然后点击导出按钮下载 CSV 文件。
这种流程在业务系统里非常常见。写脚本之前，我会先手动打开浏览器走一遍流程，同时打开开发者工具，观察每一个按钮、输入框的稳定属性。重点看四件事：
- 登录页的输入框和按钮是否有稳定 id；
- 登录成功后 URL 是否会变化，比如跳转到
/dashboard； - 查询按钮点击后，哪个元素代表“查询中”的状态；
- 导出下载是否有明确提示，比如“生成中”按钮变成可点击状态。
没有这个“人工摸底”阶段，直接写代码等于盲人摸象。真实项目中，页面的 HTML 结构往往比教程里复杂得多，先看现状能帮你省掉大量试错时间。
6.2 代码实现：每一步为什么要等这个条件
下面是一个完整的示例流程，关键点都在注释和等待条件里：
import time 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.service import Service from webdriver_manager.chrome import ChromeDriverManager options = webdriver.ChromeOptions() options.add_argument("--disable-blink-features=AutomationControlled") driver = webdriver.Chrome( service=Service(ChromeDriverManager().install()), options=options ) wait = WebDriverWait(driver, 15) try: # 1. 打开登录页 driver.get("http://example.com/login") # 2. 等待用户名输入框可见，再输入账号 wait.until(EC.visibility_of_element_located((By.ID, "username"))).send_keys("demo_user") driver.find_element(By.ID, "password").send_keys("demo_pass") # 3. 等待登录按钮可点击，点击后等待 URL 变化 wait.until(EC.element_to_be_clickable((By.XPATH, "//button[contains(text(),'登录')]"))).click() wait.until(EC.url_contains("dashboard")) # 4. 进入查询页：用链接文本跳转，并等待页面元素 driver.find_element(By.LINK_TEXT, "订单查询").click() wait.until(EC.visibility_of_element_located((By.ID, "date_start"))) # 5. 输入日期范围 driver.find_element(By.ID, "date_start").send_keys("2025-01-01") driver.find_element(By.ID, "date_end").send_keys("2025-01-31") # 6. 点击查询，等待结果总数出现 wait.until(EC.element_to_be_clickable((By.ID, "search_btn"))).click() wait.until(EC.text_to_be_present_in_element((By.ID, "result_total"), "条")) # 7. 点击导出，等待文件下载完成（这里简单用等待演示） driver.find_element(By.ID, "export_btn").click() time.sleep(5) finally: driver.quit()这里面每一步都不是瞎等的。url_contains("dashboard")是在等登录逻辑真正完成，而不是等页面停滞；text_to_be_present_in_element是在等查询结果渲染出来。如果直接把查询按钮点击后的逻辑接到“立即点击导出”，很可能导出的还是上一次查询的缓存数据。
6.3 异常处理与日志输出：把失败现场留下来
脚本一旦用于长期巡检，一定会遇到各种环境问题。最怕的不是报错，而是报错后你完全不知道现场发生了什么。我习惯在任何关键业务操作外面套一层保护逻辑：
try: run_main_flow() except Exception: # 保存当前页面状态 driver.save_screenshot(f"failure_{time.strftime('%Y%m%d_%H%M%S')}.png") with open(f"failure_{time.strftime('%Y%m%d_%H%M%S')}.html", "w", encoding="utf-8") as f: f.write(driver.page_source) # 同时打印关键信息 print("current_url:", driver.current_url) print("page_title:", driver.title) raise保存 HTML 快照尤其重要，因为截图只能看到视觉信息，页面源码却包含元素的属性、请求状态、隐藏的错误信息。等到排查问题时，这两样东西能让你精准定位页面处于什么状态。
日志方面，我建议在每一步关键节点打印中文说明，比如“已登录成功”“已进入查询页”“开始等待导出结果”。长期运行的脚本，有日志才有办法回溯问题发生的完整链路。
7. 常见问题与排查技巧实录
7.1 元素找不到、点击失效时，按什么顺序排查
遇到NoSuchElementException或者ElementNotInteractableException，我不是马上改定位表达式，而是按下面顺序过一遍：
- 页面是不是真的加载完了？用显式等待，而不是
sleep。 - 目标元素是不是在 iframe 里？先
switch_to.frame。 - 有没有弹窗或遮罩层挡在上面？如果有，先操作弹窗关闭按钮。
- 元素在 DOM 里但不可见？可能是
display:none，需要先展开或滚动到它。 - 是不是有多个匹配元素？用
find_elements看看数量，确认你选的是不是第一个。 - 是否浏览器窗口太小，元素被折叠？必要时先最大化窗口。
点击失效还有一种隐蔽原因：元素位置被某个浮动层覆盖，element.click()的默认行为是点击元素中心点，如果中心点被遮挡，就会失败。这时可以试试用 ActionChains 移动鼠标到元素再点击，或者用 JS 点击作为兜底。
7.2 弹窗、新标签页、验证码场景怎么处理
普通 alert 弹窗处理非常直接：
alert = driver.switch_to.alert alert.accept() # 点击确定 alert.dismiss() # 点击取消新标签页的问题也很高频。比如点击一个“查看详情”按钮，浏览器新开了标签页，但 Selenium 的当前句柄还停留在旧页面。你需要主动切换：
for handle in driver.window_handles: driver.switch_to.window(handle)之后用driver.current_url判断有没有切到目标页。如果有多个标签页，就按 URL 或者标题来筛选，而不是简单切到最后一个。
验证码是个特殊场景。自动化测试里遇到验证码，最优解不是去破解，而是让测试环境支持“人工介入”或者使用测试专用的万能码。如果线上环境遇到验证码，最好的处理是把脚本停下来，通知人工去处理，而不是写一堆暴力识别逻辑。任何绕过验证码的方案都涉及安全对抗边界，既不推荐，也不应该在无人授权的情况下使用。
7.3 维护心得：如何让 Selenium 项目不再“脆弱”
Selenium 脚本维护成本高，很大原因是页面结构经常改。每改一次按钮 class，脚本就要跟着改。减少这类维护痛苦，我最有心得的是两件事：页面对象模型和等待条件收敛。
页面对象模型不是高深概念，就是把一个页面的定位器和操作逻辑封装成类。登录页有登录页的类，查询页有查询页的类。以后这个页面改了，只需要改对应类里的一个定位器，而不是在 100 处调用位置改 100 遍。
另一个心得是：不要让脚本里到处都是某个特征字符串。把选择器统一放到类属性里，关键超时时间也统一提取为常量。这样出问题时，你不需要读完整段代码才知道“这里原来用的是 15 秒超时”。
驱动升级也需要纳入维护计划。浏览器驱动版本不匹配，是脚本突然跑不起来的高频原因。我会在每次浏览器大版本升级后，第一时间用webdriver-manager重新拉取驱动，并把当前稳定版本记录在项目说明里，方便其他人复现环境。
最后说一点个人经验：真正让 Selenium 变得好用，靠的不是背 API，而是调试习惯。每次失败先问自己三个问题——现在在哪个 iframe？元素是不是真的可见？上一个异步请求到底走完没有？把这三个问题养成条件反射，你遇到的绝大多数奇怪问题都能在一分钟内找到方向。这套玩熟练之后，你会发现“像真人一样操作浏览器”并不是玄学，它其实就是一件把细节做扎实的工程活。
