1. Selenium是什么, 以及为什么我还在用它
先亮个观点: 到现在为止, 还有人在争论"自动化该用 Selenium 还是 Playwright", 而我的回答一直是——先把 Selenium 吃透再说。它不是效率最高、也不是语法最优雅的工具, 但它是理解"浏览器自动化"这件事最好的入门路径, 也是生产环境里坑最浅、资料最全、兼容性最稳的方案之一。
Selenium 的本质, 按我的理解, 是"一套远程控制浏览器的标准化协议 + 各语言的客户端库"。它允许你用代码去驱动真实的 Chrome、Firefox、Edge 浏览器, 模拟人的操作: 打开网页、点按钮、填表单、翻页、抓数据、截图, 甚至执行 JavaScript。它能做的远不止自动化测试, 我身边同事用它做数据采集、后台批量处理、定时巡检、报表截图, 甚至是给不善用系统的运营同学做"一键操作小工具", 都跑得稳稳的。
这篇文章不是从零开始的语法手册, 而是我压箱底的使用经验: 核心组件怎么协作、常用函数怎么用才不踩坑、等待策略如何设计、真实项目的完整脚本长什么样, 以及在各种诡异报错面前怎么一步步定位。无论你是刚接触自动化的新人, 还是写过不少脚本但总被偶发问题搞心态的熟手, 这篇都值得你花十分钟过一遍。
2. 拆开Selenium: 核心组件和工作原理
2.1 三个核心组件: Client, WebDriver, Browser Driver
Selenium 的体系可以拆成三块: 客户端库(Client Library)、WebDriver 协议(现在更准确说是 W3C WebDriver 标准)、浏览器驱动(browser driver)。
客户端库就是我们 pip install selenium 之后, 在 Python 代码里 import 的那个东西。它本身不操作浏览器, 它的职责是把我们的操作意图——比如"打开这个URL""找到那个输入框""点击这个按钮"——翻译成一套标准化的指令。
这套指令通过网络(默认是本地回环地址的某个端口)发送给浏览器驱动。浏览器驱动是各浏览器厂商或 Selenium 团队提供的可执行文件, 比如 chromedriver、geckodriver、edgedriver。驱动收到指令后, 再通过浏览器内部的原生自动化接口去真正操作浏览器。
你可能会问: 为什么中间要多一个驱动, 而不是客户端库直接连浏览器? 两个原因。一是安全和隔离, 浏览器并不想被任意进程随意操作, 通过驱动这个"中间人", 浏览器可以校验指令来源、控制权限; 二是标准化, 不同浏览器内部实现差异巨大, Selenium 通过驱动层屏蔽了这些差异, 让代码只需要写一套, 就能跑在 Chrome、Firefox、Edge 上。
这三者的关系可以简单理解成: 脚本是司机, 驾驶指令是交规, 驱动是车辆的中控系统, 浏览器是车本身。司机不需要知道发动机怎么点火, 只要会踩油门打方向盘就行。
2.2 定位与执行链路: 从代码到页面元素
Selenium 的每一次操作, 本质上都是一条链路: 构造指令 → 发送给驱动 → 驱动调用浏览器接口 → 浏览器渲染进程执行 → 返回结果。
举个具体例子。假设我要执行这段代码:
from selenium import webdriver from selenium.webdriver.common.by import By driver = webdriver.Chrome() driver.get("https://example.com") search_box = driver.find_element(By.ID, "search") search_box.send_keys("selenium") search_box.submit() driver.quit()第一步, driver.get() 会告诉驱动: 请导航到这个地址。驱动让浏览器去加载页面。此时脚本会阻塞等待, 直到页面触发 load 事件(严格说是"页面加载完成"状态), 才会继续往下走。注意, "页面加载完成"不代表"你要的元素准备好了", 这一点后面展开讲。
第二步, find_element(By.ID, "search") 会向浏览器发送"查找元素"的指令。浏览器返回的是该元素的一个引用(一个类似句柄的东西), 而不是元素内容本身。
第三步, send_keys 又把"输入文字"指令和这个句柄绑定, 发送给浏览器执行。
这里有个重要概念: Selenium 的操作是"发指令-等结果"的串行模式, 而不是"流水线管道"。每一步都要等浏览器真正执行完成后, 脚本才会收到响应。所以脚本执行速度的上限, 很大程度取决于浏览器的反应速度, 而不是 Python 的执行速度。
这也是为什么后面要讲显式等待——因为浏览器加载页面、渲染元素都是异步的, 如果脚本在元素还没出现时就去找它, 自然会报 NoSuchElementException。
2.3 WebDriver 是协议还是工具? 一个常见误解的澄清
很多初学者把 WebDriver 和 Selenium 划等号, 甚至认为 WebDriver 就是 chromedriver 那个小文件。这里多说一句: WebDriver 是一套协议标准, 定义了"客户端如何描述操作意图""驱动如何响应""错误如何编码"等一系列规范。
Selenium 4 之后, Selenium 全面拥抱了 W3C WebDriver 标准。这意味着只要是实现了这套标准的驱动, 都能被 Selenium 客户端驱动起来。这也是为什么新版的 chromedriver 不再需要额外手动匹配端口、启动方式也更干净的原因之一。
还有一个常见误解: Selenium 只能做自动化测试。说实话, 它的诞生确实是为了测试, 但我在生产环境里的用法早就超出了测试范畴。数据采集、表单自动填充、内容批量发布、定时截图巡检、甚至是给内部同事做的"一键批量操作"小工具, 都是 Selenium 发挥价值的地方。理解这一点, 你就不会把思路局限在"测试框架"四个字里。
3. 环境准备: 版本匹配是第一道门槛
3.1 安装与版本对应关系
Selenium 的环境准备, 核心就一句话: 版本匹配。这里的"版本"至少涉及三层: Python 版本、Selenium 包版本、浏览器驱动版本, 还有浏览器本身的版本。任何一个错位, 都会导致启动时报错。
以 Chrome 为例, 你需要保证 chromedriver 的主版本号和 Chrome 浏览器主版本号一致。比如本机 Chrome 是 120.0.x, 就应该下载 120.x 的 chromedriver。如果不匹配, 启动 WebDriver 会直接抛 SessionNotCreatedException, 而且报错信息里通常很明确地写着版本相关字样。
安装 Selenium 本身很简单:
pip install selenium但注意: 只装 Selenium 是不够的, 还得有浏览器和对应的驱动。Chrome 驱动可以在 Chrome 官方提供的地址下载; Firefox 则用 geckodriver。下载解压后, 通常需要把驱动文件放到 PATH 环境变量里, 或者在代码里用 Service 对象显式指定路径。
Selenium 4.6 之后的版本有一个很方便的特性: Selenium Manager。当你没有手动配置驱动、也没设置相关环境变量时, 它会尝试自动下载匹配浏览器版本的驱动。这个功能对新手极其友好, 但我在公司内网环境里会显式禁用或手动配置, 因为内网访问不了外网, 自动下载会卡住, 一卡就是几十秒。
3.2 配置驱动的三种姿势
结合我的实际使用, 配置 chromedriver 有三种姿势, 按推荐程度排列。
第一种, 使用 Selenium Manager 自动管理。什么都不用管, 写上 webdriver.Chrome() 即可, 适合本地开发和个人脚本。
第二种, 手动指定驱动路径。用 Service:
from selenium.webdriver.chrome.service import Service service = Service(executable_path="/opt/chromedriver/chromedriver") driver = webdriver.Chrome(service=service)这种方式适合公司内网、CI 环境、或者驱动放在固定目录的情况, 可控性最好。我自己的服务器脚本基本都是这个写法, 因为路径和版本自己心里有数。
第三种, 把驱动目录加入 PATH。适合只在本机折腾、且只有一个浏览器驱动的情况。好处是代码简洁, 坏处是一旦机器上装了多个不同版本的驱动, 环境变量一乱就容易串版本。
这里还有一个我自己常用的操作: 把驱动版本选择逻辑封装成一个小函数, 从浏览器安装路径读取版本, 再拼接出对应驱动路径。这样换浏览器版本时, 脚本不会突然崩掉。代码不复杂, 但非常实用。
3.3 启动参数: Options 不只是摆设
Options 是很多人忽略但其实极其有用的部分。它相当于启动浏览器时的开关集合。我日常最常用的几个:
from selenium.webdriver.chrome.options import Options options = Options() options.add_argument("--headless=new") # 无头模式, 不弹出浏览器窗口 options.add_argument("--disable-gpu") # 禁用GPU, 无头模式下的老配置 options.add_argument("--no-sandbox") # 以root运行时必须, 否则崩溃 options.add_argument("--window-size=1920,1080") # 设定窗口尺寸 options.add_argument("--disable-blink-features=AutomationControlled") # 隐藏自动化特征无头模式(headless)是最常用的省资源方案: 浏览器不渲染界面, 但执行逻辑和真实浏览器几乎一致。对于跑在服务器上的定时任务, 这是首选。但要注意, 无头模式下有些网站的行为会和有头模式略有差异: 字体渲染、某些动画、甚至验证码的出现频率可能都不一样。如果排查诡异问题时, 可以先切回有头模式看看, 这一步能省掉很多冤枉路。
隐藏自动化特征这个参数, 单独说一下。某些站点会通过检测 navigator.webdriver 属性来判断是否被自动化控制。加上这个参数后, 属性会被置为 false, 能降低被拦截的概率, 但不是绝对保险。真想提高隐蔽性, 还需要配合 CDP(Chrome DevTools Protocol)做更底层的处理, 这个展开就又是一篇文章了。
4. 核心函数库: 页面交互与元素操作
4.1 查找元素: find_element 与 find_elements
查找元素是 Selenium 所有操作的前置条件。找不到元素, 后续的点击、输入、断言全都无从谈起。Selenium 提供了八种定位方式, 常用的有 ID、Name、Class Name、CSS Selector、XPath 等。
# 单个元素 element = driver.find_element(By.ID, "username") # 多个元素, 返回列表 elements = driver.find_elements(By.CLASS_NAME, "item") # 链式查找: 在某个元素内部继续查找 card = driver.find_element(By.CLASS_NAME, "card") button = card.find_element(By.CSS_SELECTOR, "button.submit")这里说几个实际经验。一是定位方式优先顺序: ID 优先, 其次 CSS Selector, 再其次 XPath。因为 ID 最稳定、最快; CSS Selector 简洁且性能好; XPath 功能最强大, 但写不好容易又长又脆, 页面结构稍微一改就失效。
二是 find_elements(注意有个 s) 和 find_element 的差异。find_element 找不到时会抛异常, 导致脚本中断; find_elements 找不到时返回空列表。对于"元素可能存在也可能不存在"的场景, 用 find_elements + if 判断, 比 try/except 更干净。比如判断一个弹窗是否出现:
toast = driver.find_elements(By.CLASS_NAME, "toast-message") if toast: print("弹窗内容:", toast[0].text)三是尽量别用 XPath 里的绝对路径, 比如 /html/body/div[2]/div/div[1]/form/input。这种写法对页面结构极其敏感, 只加一个 div 就全废。要写就用相对 XPath, 配合元素属性或文本来定位, 比如 //input[@placeholder='请输入用户名']。
4.2 页面导航与浏览器控制: get, back, forward, refresh
浏览器级别的控制函数看着简单, 但组合起来很有讲究。这部分按使用频率排个序:
driver.get(url) # 导航到URL, 最常用 driver.back() # 浏览器后退 driver.forward() # 浏览器前进 driver.refresh() # 刷新当前页面 driver.current_url # 获取当前URL driver.title # 获取当前页面标题driver.get() 会等页面加载完成才返回, 这点前面提过。但"加载完成"并不意味着"你要的元素准备好了", 尤其现在前端框架(React/Vue)大量使用异步渲染, DOM 可能是在页面 load 事件触发后好几秒才出现的。这就是很多新人困惑的"get 之后立刻 find_element 报错"的原因。
back、forward、refresh 这三个, 我实际用在多页面跳转流程中比较多。比如先登录页 → 再跳首页 → 再回登录页校验某些状态。注意: 如果页面里有 window.open 打开的新标签页, back() 只会影响当前标签页的历史记录, 不会跨页签回退。跨页签操作要用 window 句柄切换, 这个放到后面讲。
current_url 和 title 是属性而不是方法, 不需要加括号。我经常用它俩做页面跳转后的断言, 比截图省事。比如:
driver.find_element(By.LINK_TEXT, "关于我们").click() assert "about" in driver.current_url4.3 元素操作: click, send_keys, clear, submit
元素级别的操作函数, 是 Selenium 脚本里出现频率最高的。逐个说。
click() 是点击元素。它模拟的是鼠标点击, 但注意它并不关心元素是否可见、是否被遮挡。如果元素被其他 div 挡住, 或者还在渲染中, 点击可能静默失败——不报错, 但页面没反应。这是最坑的场景之一, 排查时先看看元素是否真的可以点击。
send_keys() 用于输入文字, 也可以输入键盘按键, 输入特殊键要从 Keys 里导入常量:
from selenium.webdriver.common.keys import Keys input_box = driver.find_element(By.ID, "q") input_box.send_keys("selenium") input_box.send_keys(Keys.ENTER) # 按回车一个细节: send_keys 是"追加"输入, 如果输入框里已有默认值, 需要先 clear() 再输入, 否则文字会接在后面。
clear() 清空输入框。老实说, 这个方法对原生的 input 和 textarea 很好用, 但对一些自定义封装的组件(比如带前缀后缀的复合输入框)可能不起作用。遇到这种情况, 我一般用 Ctrl+A 全选后删除的变通方案:
input_box.send_keys(Keys.CONTROL, "a") input_box.send_keys(Keys.DELETE)submit() 是提交表单。它等价于触发表单的 submit 事件。在表单只有一个输入框时, 按回车和 submit() 效果类似。但 submit() 有个局限: 它只会调用就近 form 里的提交逻辑, 如果按钮是 div 绑定的 click 事件而不是原生 submit, 那 submit() 就失效了。所以我现在更习惯直接定位"登录""确定"按钮再 click(), 通用性更强。
4.4 表单处理: 下拉框、复选框、单选按钮
Web 页面的表单远不止文本框一种。下拉框、复选框、单选框各有各的坑。
下拉框如果是原生 select 元素, 最标准的做法是使用 Select 类:
from selenium.webdriver.support.ui import Select select = Select(driver.find_element(By.ID, "city")) select.select_by_value("beijing") # 按value属性选择 select.select_by_index(2) # 按索引选择 select.select_by_visible_text("北京") # 按可见文本选择select_by_visible_text 是最直观的, 但注意文本必须完全匹配, 有空格都算匹配失败。如果下拉框是被二次封装过的非原生组件, Select 类就不适用了, 只能先点击触发下拉展开, 再在展开的层里找目标选项。这种组件的写法高度依赖页面结构, 没有通用方案, 需要具体页面具体分析。
复选框和单选按钮, 本质上是先确认它的状态, 再决定是否需要点击。很多时候脚本点击前, 元素已经处于选中状态, 再点反而会取消选中。我习惯先读取是否选中:
checkbox = driver.find_element(By.NAME, "agree") if not checkbox.is_selected(): checkbox.click()is_selected() 对于原生 checkbox 和 radio 是可靠的。但对那些用背景图、伪元素做的"假复选框", is_selected() 往往返回 false——因为真正的 input 被隐藏了, 页面上看到的只是视觉替身。这种情况我一般直接点击对应的 label 或容器元素, 而不是点那个隐藏的 input。
5. 等待机制: 为什么你的脚本总在"元素找不到"上报错
5.1 隐式等待与显式等待的真正区别
等待是 Selenium 脚本稳定性的分水岭。没有合理等待的脚本, 就是一颗定时炸弹, 今天能跑, 明天不一定。
隐式等待(implicitly_wait)是设置一个全局超时时间。它作用在 find_element 和 find_elements 上: 当元素没有立刻出现时, 驱动会轮询等待一段时间, 直到超时为止。
driver.implicitly_wait(10) # 全局最多等10秒显式等待则是针对某个条件, 在指定时间内反复检查, 直到条件成立或超时。最常用的是 WebDriverWait 搭配 expected_conditions:
from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait = WebDriverWait(driver, 10) element = wait.until(EC.presence_of_element_located((By.ID, "login-btn")))两者最大的区别是作用范围和失效速度。隐式等待是"轮询所有元素查找", 而显式等待是"针对特定条件"。隐式等待在某些 Selenium 版本和浏览器组合下, 对 find_elements 的表现并不可靠, 而且它没办法处理"元素存在但不可点击"这类更复杂的情况。显式等待则能精确控制"什么时候继续执行"。
我个人的建议: 能用显式等待就不用隐式等待。隐式等待设置一个 5 秒作为兜底, 关键操作全部用显式等待。这样既不至于脚本执行太慢, 又能保证稳定性。
5.2 常用等待条件: 从出现到可点击再到消失
expected_conditions 模块里封装了大量常用的等待条件, 我用得最多的有这么几个:
EC.presence_of_element_located((By.ID, "x")) # 元素在DOM中出现 EC.visibility_of_element_located((By.ID, "x")) # 元素可见 EC.element_to_be_clickable((By.ID, "x")) # 元素可见且可点击 EC.staleness_of(element) # 元素被移除/重绘 EC.text_to_be_present_in_element((By.ID, "x"), "完成") # 元素包含指定文本presence 和 visibility 是新人最容易混淆的。presence 只要 DOM 里有这个节点就算满足, 哪怕它在屏幕外或 display:none; visibility 则要求元素非隐藏、有尺寸、能看见。对用户交互来说, visibility 和 clickable 更有意义。
staleness_of 我特别说一下: 它用于判断一个元素是否已经"失效"。这在 SPA(单页应用)里很有用——点击某个操作后, 页面局部刷新, 原来拿到的元素引用就不再有效。此时再用旧元素去操作, 会报 StaleElementReferenceException。这个异常是 Selenium 新手最常遇到的坑之一, 解法就是用 WebDriverWait 等旧元素失效、再重新定位新元素, 而不是用旧引用硬撑。
5.3 显式等待的底层: 轮询与超时
显式等待底层其实就是一个轮询循环: 每隔一段时间(默认 poll_frequency 是 0.5 秒), 检查一次条件是否满足; 如果满足, 立即返回, 否则继续; 直到超时, 抛出 TimeoutException。
# 自定义轮询间隔的写法 wait = WebDriverWait(driver, timeout=10, poll_frequency=0.2)把 poll_frequency 调小, 能让条件检测更频繁, 适合响应极快的页面交互; 调大则减少无效请求, 适合等待长时间任务。绝大多数场景用默认 0.5 秒就够了, 没必要频繁改动。
等待条件里传入的定位元祖, 我见过很多同事写成:
EC.presence_of_element_located((By.ID, "x")) # 少一个括号就报错这里必须是双括号: 第一个括号是函数调用的参数, 里面又是一个元组。少一层就是传了两个参数, 直接 TypeError。这种低级错误我见过不下五次, 写出来提醒一下。
6. 进阶操作: 窗口句柄、Cookie、截图与执行脚本
6.1 多窗口与iframe: 不切换就操作不了的烦恼
现在很多网站喜欢弹新标签页, 或者用 iframe 嵌入内容, 这两个场景都要求脚本具备"切换上下文"的能力。
多窗口场景: 点击某个链接后, 新页面在新标签页打开。此时 Selenium 的焦点还在旧页签, 需要切换:
handles = driver.window_handles driver.switch_to.window(handles[-1]) # 切到最新打开的页签这里有个细节: handles 是当前浏览器所有页签的句柄列表, 顺序并不严格代表打开顺序。更稳妥的做法是记录切换前的句柄, 然后等待新句柄出现。如果同时开多个页签, 我通常先获取句柄集合, 再用当前 URL 或标题来识别该切到哪个。window_handles 这个属性在 Selenium 4 中已经全面支持。
iframe 场景: 页面里嵌着另一个文档, 不切进去就找不到里面的元素。
driver.switch_to.frame("iframe-name") # 按name或id切换 driver.switch_to.frame(driver.find_element(By.TAG_NAME, "iframe")) # 按元素切换 driver.switch_to.default_content() # 切回主文档iframe 是可以嵌套的, 切进去一层, 再切里层, 得一层层来。切回主内容区时, 用 default_content() 一步到位。这里最坑的是 iframe 的 name 或 id 不固定, 页面每次加载可能变化。遇到这种, 我直接用元素定位, 或者按 iframe 的次序(switch_to.frame(0))来切。
6.2 Cookie 操作与登录态复用
Cookie 操作的核心价值, 就是"复用登录态"。比如脚本每次启动都要登录一次, 而登录往往伴随验证码或短信验证, 很烦人。解决办法是: 第一次手动登录成功后, 把 Cookie 保存下来; 后续脚本启动时, 直接加载 Cookie, 绕过登录。
# 保存Cookie import pickle cookies = driver.get_cookies() with open("cookies.pkl", "wb") as f: pickle.dump(cookies, f) # 加载Cookie with open("cookies.pkl", "rb") as f: cookies = pickle.load(f) driver.get("https://example.com") # 先访问一次, 域名生效后添加Cookie for cookie in cookies: driver.add_cookie(cookie) driver.refresh()注意细节: add_cookie 之前, 必须先访问一次该域名的页面, 否则 Cookie 加不进去。而且 Cookie 有域名作用域, 存的时候是哪个域名, 加载时也要在同一个域名下。保存的 Cookie 如果过期了, 加载之后依旧要重新登录, 所以这个方案适合短周期任务, 不适合隔很久才跑一次的脚本。
get_cookies() 返回的 Cookie 字典里包含 name、value、domain、path、expiry 等字段。pickle 存下来是二进制文件, 注意别提交到公共代码仓库, 里面很可能包含敏感会话信息。
6.3 截图与错误排查: 让脚本自己记录"案发现场"
脚本跑挂了, 第一件事是看"当时页面发生了什么"。截图是性价比最高的排查手段之一。
driver.save_screenshot("screenshot.png") # 保存网页截图(PNG) driver.get_screenshot_as_base64() # 返回base64编码, 方便后续上传或压缩截图的粒度, 我建议配合异常处理一起用。在关键步骤的外层包 try/except, 捕获异常的那一刻立刻截图, 顺便把页面标题、当前 URL 一起打出来。这样排查问题时, 不需要靠猜。
更细的定位方式, 是对某个元素单独截图:
element = driver.find_element(By.ID, "captcha") element.screenshot("captcha_element.png")这个在调试弹窗、验证码区域特别有用。有时候整页截图会被滚动条或弹层遮挡, 元素截图反而能反映真实问题。
6.4 execute_script: 绕过"做不到"的最后手段
有些页面的操作, 用标准的 Selenium API 就是实现不了, 或者实现了也极不自然。这时候, execute_script 就像一把万能钥匙, 直接注入 JavaScript 在页面上下文里执行。
# 修改页面元素的样式 driver.execute_script("arguments[0].style.display = 'block';", element) # 获取页面性能数据 performance_data = driver.execute_script("return window.performance.timing;") # 执行滚动 driver.execute_script("window.scrollTo(0, document.body.scrollHeight);") # 直接设置value并触发事件 driver.execute_script("arguments[0].value = 'text'; arguments[0].dispatchEvent(new Event('input', {bubbles: true}));", element)我对 execute_script 的态度是: 尽量少用, 但必须会用。少用是因为它绕过了 Selenium 的等待、可见性校验, 容易掩盖真实页面的问题; 必须会用是因为有些场景只有它能救场。比如某些 React 组件对输入做了劫持, 用 send_keys 输入第一次后, 组件状态没同步, 这时用 JavaScript 直接设置 value 并派发 input 事件, 反而能生效。这个技巧被前端框架的自动化测试反复用到, 确实实用。
我特别提醒: execute_script 返回值的类型要心里有数。如果脚本最后没有 return, 返回的就是 None; return 一个 DOM 元素时, 返回的是 WebElement 对象, 可以继续调用 Selenium 方法; return 的是数组或对象时, 会被转成 Python 列表和字典, 但嵌套太深的对象可能被截断。
7. 项目实战: 一个可复用的数据采集脚本范例
7.1 需求描述与脚本设计思路
前面讲了那么多函数和原理, 如果不串一个完整案例, 总觉得差了点什么。我拿一个真实的需求来做示范: 从一个需要登录的分页列表页面, 抓取若干字段, 保存到 CSV。
需求拆解出来其实是四件事: 登录复用、遍历分页、抓取字段、结果落盘。
这个需求里, 登录不复用就太痛苦了, 所以我把 Cookie 复用放在第一步; 分页遍历考验的是等待和页面切换; 抓取字段考验的是定位精度; 落盘则是数据清洗前的最后一步。
脚本的完整代码我贴出来, 然后逐段解释为什么这么写。整个脚本侧重的是"稳定跑完"而不是"跑得快", 因为自动化脚本最怕跑到一半挂了, 剩下的数据还得人工补。
7.2 完整代码与逐段注解
import csv import pickle 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 def create_driver(): options = webdriver.ChromeOptions() options.add_argument("--headless=new") options.add_argument("--no-sandbox") options.add_argument("--window-size=1920,1080") service = Service("/opt/chromedriver/chromedriver") driver = webdriver.Chrome(service=service, options=options) driver.implicitly_wait(5) return driver def load_cookies(driver, url): driver.get(url) try: with open("cookies.pkl", "rb") as f: cookies = pickle.load(f) for cookie in cookies: driver.add_cookie(cookie) driver.refresh() print("Cookie加载完成") except FileNotFoundError: print("没有找到Cookie文件, 请先手动登录一次") def collect_page_data(driver): rows = driver.find_elements(By.CSS_SELECTOR, "table tbody tr") page_data = [] for row in rows: cells = row.find_elements(By.TAG_NAME, "td") if len(cells) >= 4: page_data.append({ "name": cells[0].text.strip(), "status": cells[1].text.strip(), "owner": cells[2].text.strip(), "updated_at": cells[3].text.strip(), }) return page_data def main(): driver = create_driver() url = "https://example.com/dashboard/list" load_cookies(driver, url) all_data = [] for page in range(1, 6): wait = WebDriverWait(driver, 10) wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, "table tbody tr"))) all_data.extend(collect_page_data(driver)) # 尝试翻页: 点击下一页按钮 next_btn = driver.find_elements(By.CSS_SELECTOR, "a.next-page") if not next_btn: print(f"第{page}页没有下一页按钮, 结束翻页") break next_btn[0].click() time.sleep(1) # 给页面一点缓冲, 具体等待交给下一次循环的显式等待 # 写入CSV with open("result.csv", "w", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=["name", "status", "owner", "updated_at"]) writer.writeheader() writer.writerows(all_data) print(f"采集完成, 共{len(all_data)}条数据") driver.quit() if __name__ == "__main__": main()第1段 create_driver: 把驱动和浏览器初始化封装成一个函数, 方便替换浏览器类型。这里加 --headless=new 是因为新版 Chrome 无头模式更稳定, 旧写法 --headless 在新版已不建议用。
第2段 load_cookies: 先 driver.get 一次, 让域名生效, 再 add_cookie, 然后 refresh。注意这里用了 try/except FileNotFoundError, 如果第一次跑没有 Cookie 文件, 也不会崩溃, 而是给出提示。
第3段 collect_page_data: 按 CSS 选择器找到表格所有行, 再逐行拆单元格。我特意用了 find_elements 而不是 find_element, 保证"当前页没有数据"时返回空列表, 不会抛异常。
第4段 main: 外层 for 循环控制页数。每页先显式等待表格行出现, 再采集, 再找下一页按钮。这里我用了 find_elements 判断下一页是否存在, 是为了避免最后一页报 NoSuchElementException。click 之后没有立刻做复杂的等待, 而是留给下一次循环开始时的显式等待, 这样逻辑简单且稳定。
输出编码用 utf-8-sig, 是防止 Excel 打开 CSV 时中文乱码。这不是 Selenium 的问题, 而是数据落盘时最常见的坑, 我在这个项目里顺手就规避了。
7.3 这个脚本踩过的两个真实问题
这个脚本我在实际跑的时候, 遇到过两个印象深刻的问题。
第一个是"点击下一页后, 页面内容是上一页的残留"。原因是点击后浏览器立刻进入了跳转, 但表格里的 DOM 还没来得及刷新, 我的采集函数又立刻执行了, 结果把同一页数据抓了两遍。解决方法是: 不要只靠 sleep 固定等待, 而是在每次采集前, 显式等待表格中第一行数据的文本发生变化。这比任何固定 sleep 都可靠。
第二个问题是"表格在无头模式下只渲染了可见区域"。有些前端表格用了虚拟滚动, 只渲染窗口内的行, 下拉滚动条之后才继续渲染后续行。无头模式下窗口高度设置不合理时, 采集到的数据会少一截。解决方法是把 --window-size 调成 1920,1080 甚至更矮, 或者改用真实滚动操作把页面拉到最底部, 触发懒加载。
这类问题不会出现在官方文档里, 只有真跑过一遍才知道。我把它们写在这里, 也是希望大家省掉那几小时的排查时间。
8. 常见报错的全排查清单: 从报错信息到根因
8.1 报错信息与应对方案速查表
自动化脚本大部分时间不在写功能, 而在对付报错。我把高频报错整理成一张速查表, 每一条都是我实际碰到过的。
| 报错信息 | 常见原因 | 应对方案 |
|---|---|---|
| NoSuchElementException | 元素不存在或定位方式不对 | 换定位方式; 检查是否在 iframe/新窗口里 |
| StaleElementReferenceException | 元素引用失效(页面刷新/DOM重绘) | 重新定位元素, 不要复用旧引用 |
| ElementNotInteractableException | 元素存在但不可见/被遮挡/只读 | 显式等待可见; 用execute_script强制操作 |
| TimeoutException | 显式等待超时, 条件始终不满足 | 检查选择器; 检查是否存在异步加载失败 |
| SessionNotCreatedException | 驱动版本与浏览器版本不匹配 | 升级/降级驱动版本, 确保主版本一致 |
| InvalidArgumentException | 参数类型不对, 如URL格式错误 | 检查传入值; 确保URL带http前缀 |
| WebDriverException | 驱动没启动/端口被占用/权限问题 | 检查驱动路径、进程占用、加--no-sandbox |
这张表我建议截图保存, 遇到报错先对号入座, 比无头乱猜快得多。
8.2 从报错到修复的完整排查链路
我拿一个最典型的场景演示完整排查链路: 脚本在某个页面执行 click 后, 一直报 TimeoutException, 等待条件是 visibility_of_element_located, 目标是下一屏的确认按钮。
第一步, 我会先检查等待条件里的选择器在当前页面到底匹配到什么。最快的办法是打开浏览器开发者工具, 在 Console 里执行 document.querySelectorAll("选择器"), 看有没有返回值。有返回值但不可见, 问题是 CSS 或遮挡; 没有返回值, 问题是选择器或加载逻辑。
第二步, 如果选择器没问题, 那就要看点击是否真的生效。我会在 click 前后各打一条日志, 记录当前 URL 和页面标题变化。如果 URL 没变, 说明点击事件可能没触发; 如果 URL 变了但目标元素还是没出现, 说明新页面又出了别的问题。
第三步, 我会把无头模式切回有头模式, 人工观察页面到底停在哪个状态。这一步往往能直接看见问题: 可能是异步接口报错了, 页面弹出了错误提示; 也可能是弹窗被遮住了, 等待条件没等到的元素根本被一个透明遮罩盖着。
这个链路的核心思想是"分层排除": 先确认定位对不对, 再确认操作有没有触发, 最后确认环境差异。不要一上来就怀疑 Selenium 的 bug——绝大多数情况下, 是我们对页面状态的判断不够准确。
8.3 日志与诊断: 让脚本自己说清楚"死在哪一步"
脚本跑挂不可怕, 可怕的是挂了之后信息全无。我强烈建议在关键步骤周围加上结构化日志。
我在项目里常用的做法, 是维护一个"执行清单"列表, 每完成一步就往列表里追加一步名称, 异常时把已完成的步骤用一条日志打出来:
steps = ["打开浏览器", "加载Cookie", "进入列表页", "第1页采集", "翻到第2页"] # 某一步异常时 import logging logging.basicConfig(level=logging.INFO) logger = logging.getLogger("auto") logger.info("已完成步骤: %s", " -> ".join(steps)) logger.exception("异常信息: ")这样排查时会轻松很多。如果再配合截图, 基本能定位到具体是哪一步出了问题。我把这个"步骤追踪 + 异常截图"的组合, 称为自动化脚本的最后一道防线。宁可多写三行日志, 也不要被困在现场一无所知。
9. 效率与稳定性: 我从项目里沉淀的提升方案
9.1 等待策略与超时设计
稳定的自动化脚本, 核心是管理好不确定性。等待策略就是其中最重要的部分。
我自己的设计原则是三层等待: 第一层, 全局隐式等待设 5 秒, 兜底用; 第二层, 关键交互前用显式等待, 等具体条件; 第三层, 完全没有规律的场景, 才用固定 sleep, 比如等一个异步任务跑完再刷新查询结果。
固定 sleep 是万不得已的选择, 因为它在环境快的机器上浪费时间, 在环境慢的机器上又不够用。如果非要 sleep, 我建议配合重试机制: 第一次等待后检查条件, 不满足就再等一轮, 最多重试 N 次。这样比一次性 sleep 30 秒稳妥得多。
9.2 超时时间到底设多少: 一个基于场景的经验值
显式等待的 timeout 到底设多少, 是新人最爱问的问题。我给一个经验参考, 具体数值要结合场景调整:
| 场景 | 建议超时 |
|---|---|
| 普通页面元素出现 | 10秒 |
| 页面跳转后关键元素 | 15秒 |
| 懒加载/异步请求完成 | 20秒 |
| 大文件上传/导出 | 60秒以上 |
这个表不是我拍脑袋写的。普通页面在正常网络环境下, 元素出现时间通常在 1-3 秒内, 超时设 10 秒已经留了裕量; 异步请求到 DOM 更新通常比首次加载快, 但网络波动可能拉长, 20 秒更稳; 大文件导出涉及服务器处理和下载, 时间不可控, 只能放宽。
超时太短导致偶发失败, 超时太长又让脚本整体执行时间变长。我常用的折中方案是把超时设在 3-4 倍于"正常运行时长", 具体数值根据实际观察动态调整。
9.3 复用模块与封装思路
跑了几十个自动化脚本后, 我最大的体会是: 不要每次从零开始。把高频操作封装成基础模块, 能极大减少重复劳动。
我自己的封装思路大概是这么几层:
第一层, 驱动初始化模块。封装不同浏览器的启动、Options 预设、驱动路径配置, 对外只暴露 create_chrome_driver() 这类函数。
第二层, 通用操作模块。封装"等待元素可见""等待元素可点击""安全点击""安全输入"等带重试、带日志的基础动作。
第三层, 业务功能模块。比如"登录""翻页""采集表格数据", 这些已经绑定具体站点结构, 单独建文件维护。
封装的重点是"边界清晰": 通用模块不写死某站点的选择器, 业务模块不包含底层驱动逻辑。这样当网站改版时, 往往只需要改业务模块里的选择器, 通用模块几乎不动。
我见过有人把所有代码堆在一个文件里, 两千多行, 每次改一个页面元素都要全局搜索, 维护成本极高。拆分成模块之后, 同样体量的项目, 维护效率能提升好几倍。
10. 常见问题解答: 我常被问到的一些问题
10.1 Selenium 和其他自动化工具怎么选
这是一个高频问题。我的观点是: 没有碾压级胜负, 关键看场景。
如果团队已经深度使用 Selenium, 或者需要同时覆盖老浏览器、老框架, Selenium 是稳妥选择。它生态成熟, 资料最多, 踩坑经验一搜一大把。
如果是从零开始的新项目, 且主要面向现代浏览器, 可以结合项目特点评估其他方案, 但 Selenium 依然能满足大部分需求。我的选择逻辑很简单: 面向长期维护的老系统, 用 Selenium; 对于全新的内部工具, 可以再调研测试。但如果你只是学自动化、做作业、跑一些小脚本, Selenium 依然是入门性价比最高的选择。
10.2 无头模式能解决一切"不弹出窗口"的需求吗
无头模式确实能省资源、适合服务器运行, 但它不是银弹。
一是无头模式和有头模式在渲染行为上有细微差异, 有些页面会因此出现不同结果; 二是一些站点会识别无头模式的特征, 从而加载不同的页面版本或验证码策略。
如果脚本在本地有头模式跑得稳稳的, 一到服务器无头模式就出诡异问题, 我通常先怀疑无头模式的渲染差异, 而不是立刻去改代码逻辑。排查方法很简单: 在无头模式下截一张图, 和有头模式截图对比, 差异往往一目了然。
10.3 哪些场景不适合用 Selenium
Selenium 虽然强大, 但确实有短板。
浏览器资源占用高, 不适合超高并发。如果要做千万级数据采集, 首选还是 API 接口, 或者用更轻量的 HTTP 请求方案。
对渲染速度极其敏感的页面, Selenium 的执行效率天然受限, 因为每一步都在等浏览器反馈。
验证码处理是另一个边界。Selenium 本身没有内置任何验证码破解能力, 遇到强验证码, 应该优先考虑业务流程优化, 比如复用会话、降低操作频率、或引入人工审核环节。合规永远是第一位的。
这些边界说法, 希望可以帮读者少走弯路, 也避免把 Selenium 用在错误的地方, 最后还抱怨工具不够好。
写到这里, 基本把我日常使用 Selenium 的完整心得都倒出来了。如果让我挑一句话总结: 别把 Selenium 当魔法, 把它当一个"能看能点能记路径的浏览器替身", 所有问题都能用这八个字去理解——它负责操作, 你负责逻辑。我踩过的坑, 绝大部分都源于对页面状态的误判, 而不是 Selenium 本身的问题。所以, 多打日志, 多截图, 多观察页面在那一刻的真实状态, 比记一百个函数签名都管用。
