爬虫实战这个方向绕不开的永远是一个问题目标站点用JavaScript渲染内容你用requests直接请求回来的只是一堆空壳标签。我这次要拆解的项目主题是“selenium抢购订单”核心思路就是让浏览器自动完成从登录、搜索、选规格、提交订单到支付的全流程。听起来有点像“机器人代购”本质上它就是一个带时序控制、异常重试和反检测策略的端到端自动化脚本。适合对爬虫有一定基础、已经写过简单请求脚本、想进一步搞定复杂交互场景的开发者参考。项目本身不复杂但坑相当多我尽量把能踩的、该避的都说清楚。1. 项目整体思路与方案选型1.1 为什么是selenium而不是直接构造请求先说个很多人都会问的问题抢购这种事requests加上并发不香吗香但前提是你能把整个下单链路完整模拟出来。现在的电商平台从打开商品详情页到真正提交订单中间隔着一整套前端状态管理商品规格选择、库存校验、优惠计算、价格快照、订单创建接口的风控校验这些环节全部依赖JavaScript在浏览器环境里生成的动态签名和Cookie联动。你用requests肉眼看到的接口参数一旦换一个会话、换一个设备指纹立刻失效。Selenium的价值在于它不是一个“假装自己是浏览器的请求库”它就是浏览器本身。它通过WebDriver协议驱动真实的Chromium内核页面里跑的JavaScript、CSS、DOM事件、异步请求全部按真实环境执行。副作用就是慢但慢换来的是“真实”这两个字。对于抢购场景真实的会话状态比发一百个假请求值钱得多。还有一个现实原因是登录态。电商平台的登录风控现在的强度已经到了手机验证码、滑块、行为轨迹识别全上的级别requests去模拟登录几乎等于自爆。selenium配合手动扫码登录把登录后的Cookie持久化到本地后续每次运行直接加载这条路是真实可行的。1.2 整体流程拆解与模块划分我在最开始写这个项目的时候就把整个流程拆成了四个独立模块分别维护互不干扰。第一个模块是会话管理负责启动浏览器、加载配置、恢复登录态。第二个模块是商品操作层负责进入商品页、选择规格、确认数量、读取价格和库存状态。第三个模块是下单执行层负责点击结算、确认订单信息、提交订单。第四个模块是异常处理与状态同步负责超时重试、页面异常检测、下单结果确认。这样拆的好处很明显如果平台改版只改了结算按钮的位置你只需要改第三个模块的定位逻辑其他部分不动。如果登录方式变了你只需要重新走一遍会话模块的登录流程。抢购场景的特性是“目标不变、路径经常变”模块化能让维护成本降到一个可接受的范围。用一张流程图来表示的话整条链路就是初始化浏览器 → 检查登录态 → 进入商品页 → 轮询等待开售时间 → 刷新库存与价格 → 执行下单 → 确认订单 → 支付跳转 → 记录结果。后面的章节我会按这个链路逐步展开细节。1.3 方案选型的几个关键权衡技术选型上我用的是Python 3.11加selenium 4.x浏览器驱动用的是ChromeDriver对应的Chromium版本。有人会问为什么不用Playwright或者Puppeteer这两个工具在有头模式下的反检测能力确实更强但selenium的生态最成熟遇到问题能搜到的案例最多对于这种“今天写完明天就要跑”的实战项目稳定和可排查比花哨更重要。另一个权衡是关于界面模式的有头模式窗口可见还是无头模式隐藏窗口。抢购场景必须用有头模式。原因很简单很多平台在支付环节要求扫码或者二次验证无头模式没法交互。另外有头模式下你可以肉眼观察脚本每一步的动作出问题能及时定位。无头模式更适合那些纯数据采集、不需要交互的任务不适合这种链路复杂的操作型脚本。还要说一个关于时序的考量。抢购的核心竞争是“快到什么程度”而selenium的每条操作之间天然有几百毫秒的延迟。为了让脚本在开售瞬间的表现接近极限需要做三件事提前加载好页面、把规格选择等操作在开售前完成、开售后的动作序列不做过多的条件判断。这就像排队买限量商品你必须在开门前就站在正确的位置而不是开门后再研究怎么走。2. 关键配置与反检测细节2.1 selenium版本与driver的选配selenium 4.x和3.x的API风格差别很大最典型的差异就是定位元素的方式。3.x里常用的find_element_by_xpath在4.x里已经移除统一改成了find_element(By.XPATH, 表达式)的写法。如果你看的教程还在用旧写法运行起来会直接报AttributeError不要慌改成新写法就行。Driver管理是个容易踩坑的点。很多新手手动下载ChromeDriver然后放在项目目录里结果浏览器一升级driver版本不匹配脚本直接报session not created。我的建议是用webdriver-manager这个库它会根据你本机Chrome的版本号自动下载对应版本的driver彻底解决版本错位的问题。安装方式很简单pip install selenium webdriver-manager然后初始化的时候这样写from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager service Service(ChromeDriverManager().install()) options webdriver.ChromeOptions() driver webdriver.Chrome(serviceservice, optionsoptions)有同学会问为什么不用Edge或者Firefox的driver理论上都可以但我个人的经验是Chromium系和selenium的兼容性最稳社区案例也最多不要在最基础的环境选择上给自己添堵。2.2 反自动化检测的规避策略如果你的脚本在启动之后刚打开页面就被请去滑块验证那说明你的自动化特征太明显。Selenium控的浏览器在默认状态下是有一些指纹特征的比如window.navigator.webdriver这个属性是true比如浏览器窗口的尺寸、User-Agent字符串都和正常浏览器有细微差异。平台的前端风控脚本往往会先检测这些特征命中就触发验证机制。规避的办法有几个层面。第一个层面是给ChromeOptions加入一些排除参数去掉自动化控制标志options.add_argument(--disable-blink-featuresAutomationControlled) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False)第二个层面是伪造User-Agent。正常浏览器的UA里包含完整的系统信息而selenium默认的UA会带一个HeadlessChrome或者类似的标识很容易被识别。你可以先从浏览器里复制一条真实的UA然后通过add_argument(user-agent你的UA字符串)注入进去。第三个层面是伪装webdriver属性。在执行任何页面跳转之前先执行一段JavaScript把navigator.webdriver属性删掉或者重写代码大致长这样driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, { get: () undefined }); })这里用到了Chrome DevTools Protocol的addScriptToEvaluateOnNewDocument命令作用是在每一次新文档加载之前注入脚本。这个属于比较基础但有效的反检测手段配合前面几个参数一起用大部分常规场景能顺利通过。2.3 登录态保持与Cookie持久化抢购脚本绝对不能每次都重新登录一是浪费时间二是频繁登录会触发风控。正确做法是第一次运行时让浏览器弹出窗口你手动扫码登录登录成功后把Cookie保存到本地文件后续运行直接加载Cookie恢复会话。保存Cookie的代码很简单import json cookies driver.get_cookies() with open(cookies.json, w, encodingutf-8) as f: json.dump(cookies, f, ensure_asciiFalse, indent2)加载的时候需要先让浏览器打开目标域名下的任意一个页面为了建立会话上下文然后逐条添加Cookiewith open(cookies.json, r, encodingutf-8) as f: cookies json.load(f) driver.get(https://example.com) for cookie in cookies: driver.add_cookie(cookie)这里有个细节很容易被忽略Cookie是有域名和路径属性的保存和加载都要保持原样千万不要自己在JSON里删字段。还有一个经验Cookie的有效期一般就几天过期之后脚本要能检测出来并提示你重新登录。检测方式很简单加载完Cookie后跳转到个人中心页面看页面上是否还有“登录”按钮如果有说明会话已失效。3. 完整实操流程与核心代码3.1 初始化配置与浏览器加载我把项目入口文件设计成main.py启动时先读取配置文件config.json里面包含商品链接、开售时间、规格选择策略、重试次数这些参数。配置文件的好处是把“业务参数”和“代码逻辑”分开平台改规则的时候你不用动代码改配置就行。配置文件结构大致是这样{ login_url: https://example.com/login, product_url: https://example.com/item/123456, sale_time: 2024-12-01 10:00:00, spec_rules: { 颜色: 黑色, 尺寸: M }, buy_count: 1, max_retry: 5, wait_interval: 0.5 }然后初始化浏览器from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC options.add_argument(--start-maximized) options.add_argument(--disable-gpu) options.add_argument(--no-sandbox) driver webdriver.Chrome(serviceservice, optionsoptions) driver.implicitly_wait(3)启动之后先判断本地有没有可用的Cookie文件。有的话就加载没有的话就跳转登录页等手动扫码完成后自动保存。这个阶段我觉得没什么可省的登录态是整个自动化的地基地基不稳后面全是白搭。3.2 商品页的加载与规格选择等到商品链接之后脚本要做的事不是立刻点击下单而是先把页面加载到“待命状态”。什么是待命状态就是商品已经加进购物车、规格已经选好、数量和地址都确认好只等开售时间一到就提交。规格选择这块有个常见问题平台不同规格控件的类型也不同有的是一组单选按钮有些是下拉框有些是点击之后弹层。通用的处理思路是先尝试按文本定位def select_spec(driver, spec_name, spec_value): xpath f//div[contains(text(), {spec_name})]/following-sibling::div//span[contains(text(), {spec_value})] try: element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.XPATH, xpath)) ) element.click() return True except Exception as e: print(f规格选择失败: {spec_name}{spec_value}, 错误: {e}) return False为什么用contains(text(), ...)做模糊匹配因为有些元素的文本里可能包含额外的空格、角标、热卖标签之类的字符精确匹配很容易失败。模糊匹配加等待可点击状态成功率会高很多。选好规格之后页面上会显示当前的价格和库存状态。脚本要把这个信息读取出来并记录下来方便后面核对下单时价格没有变化。库存不足的时候页面会有相应的提示比如“缺货”或者“库存不足”检测到这种状态就直接跳去轮询等待而不是盲目点击。3.3 定时同步与开售抢购开售时间通常在配置文件里写死。脚本要做的是在开售前几秒钟进入一个高频率刷新页面状态的循环。这里我采用的方式是开售前2秒开始每0.3秒重新读取一次购买按钮或者提交按钮的状态。为什么要用等待轮询机制因为平台的“立即购买”按钮在开售前是不可点击的有的平台甚至会在开售瞬间才把按钮从“即将开售”切换成“立即抢购”。轮询是为了不错过这个切换的瞬间。代码大致如下import time from datetime import datetime sale_time datetime.strptime(config[sale_time], %Y-%m-%d %H:%M:%S) while True: now datetime.now() if now sale_time: break time.sleep(0.2) for attempt in range(config[max_retry]): try: buy_btn WebDriverWait(driver, 5).until( EC.element_to_be_clickable((By.XPATH, //button[contains(text(), 立即购买)])) ) buy_btn.click() print(已点击立即购买) break except Exception as e: print(f第{attempt 1}次尝试点击购买按钮失败: {e}) driver.refresh()这里有一个我自己调试多次后才总结出来的技巧在开售瞬间尽量不要刷新页面。刷新会让所有已经完成的状态初始化重新加载资源可能要花一两秒这一两秒在抢购场景里是致命的。正确的做法是在开售前就完成页面的所有准备动作开售后直接点击和提交让页面自然跳转。循环退出的时机也要注意不能以为点击了“立即购买”就万事大吉必须确认提交成功进入订单确认页。所以后面要跟一个订单页检测逻辑如果点击后3秒内没有跳转到订单确认页说明点击可能被拦截了要回到商品页重新执行。3.4 订单提交与结果确认点击“立即购买”之后浏览器会跳到订单确认页这时候要自动点击“提交订单”按钮。这个按钮的文案可能是“提交订单”也可能是“去支付”不同平台不同时期文案不一样。我习惯用关键词模糊匹配submit_btn WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.XPATH, //button[contains(text(), 提交订单) or contains(text(), 去支付) or contains(text(), 立即支付)])) ) submit_btn.click()点击提交之后页面一般会跳转到支付页面。如果看到二维码或者支付选项脚本的执行就到此为止剩下的事情交给人工。为什么不全自动支付因为支付环节涉及资金和身份验证风险很高自动支付脚本一旦出错后果很麻烦。我个人的做法是让脚本停在支付前然后用通知方式提醒我手动完成支付。这样既保证了抢购的速度又把资金操作的风险控制在可见范围内。结果确认也很重要脚本要把每次抢购的时间、订单状态、失败原因都记录到日志文件里。方便复盘到底卡在哪一步是按钮定位问题还是网络延迟问题。4. 常见问题与排查技巧实录4.1 元素定位不到元素在iframe里如果脚本点击某个按钮的时候抛出NoSuchElementException但你在浏览器里明明能看到那个按钮那第一反应应该是检查这个元素是不是被嵌在iframe里了。很多平台把支付按钮、登录弹窗、优惠信息做在iframe里selenium默认的查找范围是顶层文档完全看不到iframe内部的内容。解决方法是先切换上下文iframe driver.find_element(By.TAG_NAME, iframe) driver.switch_to.frame(iframe) # 执行元素操作 driver.switch_to.default_content()定位关键信息的时候建议把整个页面里所有iframe的id和name先打印出来确认目标元素在哪个iframe里。这个排查手段在新手阶段很管用很多元素定位问题并不是xpath写错了而是根本找错了文档层级。我曾经遇到过一层iframe套一层iframe的情况连续切换两次才拿到目标按钮没有这个意识会卡很久。4.2 被风控识别导致滑块验证即使做了反检测参数设置每天大量重复操作还是有可能触发风控。最常见的是滑块验证。一个比较现实的应对策略是降低操作频率加随机等待时间。你想想正常用户从点开页面到点击购买中间会有一点阅读和思考的时间动作间隔在几百毫秒到数秒之间波动。脚本如果每次都0.1秒完成一个动作行为轨迹本身就异常。另外浏览器的窗口大小和鼠标轨迹也在风控的采集范围内。我用过一个小技巧把窗口尺寸设置成常见的台式机显示器分辨率比如1920x1080不要用默认的800x600那种小窗口。用户代理字符串也要对应换成Windows平台的版本一致性很重要。滑块验证一旦出现脚本是没有办法直接用代码拖过去的。因为现在的滑块验证已经能识别操作系统级的鼠标轨迹代码模拟的匀速直线拖动一看就是机器。我的做法是检测到滑块验证就触发桌面通知让我手动处理处理完之后脚本继续。不要尝试用模拟拖动去对抗浪费时间和精力。4.3 库存未刷新导致下单失败抢购场景里最容易出现的一个业务问题是页面上显示有库存但点击提交订单时提示“商品已下架”或“库存不足”。出现这种情况往往是因为库存数据是异步加载的页面虽然显示有货但那是几秒前的缓存数据后台的实时库存可能在开售的一瞬间就已经被扫完了。应对办法是提高点击提交前的库存校验频率同时准备库存不足时的降级策略。降级策略可以是等待几秒后自动刷新页面重新尝试也可以是把商品页加入监控列表然后通知人工。从工程角度看你应该让脚本把“提交失败”和“提交成功”都作为正常流程输出记录当时的库存快照和时间戳这样事后分析是不是卖光了还是代码逻辑出问题就有了依据。我遇到过一种情况点击提交订单后页面上出现“正在排队”的提示等了十几秒后跳转回商品详情页。后来发现是平台在高峰期做了服务端的流量调度超额请求会被拦截回商品页。解决方式是延长超时时间不要几秒钟没反应就判定失败在不触发风控的前提下等待10秒左右再判断结果可靠性高很多。4.4 时间同步与本地时钟偏差最后一个大坑是本地系统时间不准。脚本里抢购开始的判断完全依赖datetime.now()如果本地时间比服务器时间慢几秒那开售瞬间你这边可能还在等待循环里等循环结束服务器那边的第一批库存已经被抢光了。处理办法是在程序初始化阶段做一次网络时间校准。用请求一个标准时间接口的方式获取当前精确时间计算本地时间和网络时间的偏移量然后在后续所有时间判断中加上这个偏移。代码大致思路如下import requests import time def get_network_offset(): # 请求标准时间接口 resp requests.get(https://example.com/time, timeout3) server_time resp.json()[time] local_time time.time() return server_time - local_time offset get_network_offset() sale_timestamp datetime.strptime(config[sale_time], %Y-%m-%d %H:%M:%S).timestamp() while time.time() offset sale_timestamp: time.sleep(0.1)没有网络时间校准本地时间偏差超过1秒脚本的整个时间策略就失去了意义。这个点经常被忽视但它比任何代码优化都重要。5. 实操总结与一些额外的心得整个项目做下来我最深的感受是抢购脚本的难点不在于“点击按钮”这个动作本身而在于整个链路的稳定性设计。从登录态的保持到元素定位的健壮性从时间同步到异常重试策略每一个环节都有可能成为瓶颈。你花在调试这些边缘情况上的时间远远超过写主流程的时间。我后来还做了一些扩展比如配置了运行日志的文件输出和桌面通知。日志用的是logging模块把每次操作的关键节点、耗时、状态写进当天日期的文件中。桌面通知用的是系统通知库脚本跑到支付环节就弹一条消息提醒我。这两个功能看似简单但实际使用中非常舒服尤其是日志出了故障翻一翻就知道卡在哪一步不用盯着浏览器窗口观察。再分享一个小经验不要在正式抢购前才第一次运行脚本。你至少要在开售前半小时做一次完整的预演从加载Cookie、进入商品页、选择规格到点击提交全流程走一遍。预演的时候可以故意把时间条件设成一个已经过去的时刻验证买入流程本身能不能跑通。这样开售那一刻你才能有信心而不是在紧张状态下让脚本第一跑就出各种bug。抢购的本质是概率游戏你不能控制服务器那端的排队结果但你可以把客户端这边的每个变量准备好剩下的交给时间。