Python+Selenium自动抢票脚本源码解析：登录态维持与定时触发实战

简介：这是一份面向Python爬虫与自动化爱好者的大麦网自动抢票工具源码包，适合具备一定编程基础、希望研究浏览器自动化与购票流程模拟的开发者学习参考。资源围绕热门演出票务紧张场景，通过自动刷新页面、填写购票信息并提交订单来提升抢票效率，涉及网络爬虫、JavaScript动态渲染解析、Selenium浏览器控制、多线程并发请求、验证码识别、IP代理池、数据库存储及异常重试等知识点。压缩包共6个文件，包含3个png截图、1个md说明文档、1个json配置文件与1个py核心脚本，整体约24KB，结构精简，便于快速定位入口代码与配置项。目前已有32995人学习下载，读者可借此理解自动抢票的实现原理与目录组织方式，并在此基础上按自身需求调整参数或扩展功能，同时需注意遵守平台使用条款与个人信息安全。

1. 抢票这件事，手速从来不是关键变量

去年帮朋友抢一场演出票，我盯着倒计时狂点，结果页面卡在“排队中”整整四十秒，票没了。后来复盘发现，真正的问题不是手速，而是我根本没搞懂票务平台的放票节奏和请求链路。这份“大麦网自动抢票工具”就是冲着这个痛点来的——它把“人肉点击”换成脚本轮询，把“凭感觉刷新”换成定时触发，适合那些不想每次开票都像打仗一样守在手机前的开发者。项目本身不复杂，核心就是模拟登录态、监听开票时间、自动提交订单三步，但每一步都有不少细节能翻车。下面我按“能干什么→怎么跑→怎么改”的顺序，把这份源码拆开讲一遍。

2. 项目定位与技术选型：为什么用 Python + Selenium 而不是纯接口

2.1 这个工具到底解决什么问题

先明确一点：它不是“破解”票务系统，而是把人工操作流程自动化。你手动抢票时做的动作——打开页面、登录、选场次、选票档、点提交——脚本只是把这些动作按时间轴串起来，用更稳定的节奏执行。项目正文里没写具体实现，但按这个场景的常见做法，核心能力集中在三块：登录态维持、开票时间同步、订单提交重试。登录态决定了你能不能进到选座页，时间同步决定了你是在放票瞬间发请求还是晚了两秒，重试机制决定了遇到“当前人数过多”时能不能自动再试。

适合谁用？如果你完全不懂代码，这工具对你来说门槛偏高，因为需要改配置、装环境、处理验证码。但如果你写过 Python，能看懂 Selenium 的基本操作，那这份源码就是一个现成的骨架，改改选择器、调调超时参数就能跑起来。

2.2 技术栈拆解：Selenium + Requests + 定时调度

项目用的是 Python 3 环境，依赖主要围绕三个库：

为什么不用纯 requests 直接调接口？因为票务平台的订单提交链路里混了动态 token 和浏览器指纹校验，纯接口模拟的维护成本反而更高。Selenium 虽然慢一点，但胜在稳定——页面元素变了改选择器就行，不用逆向加密参数。这也是我一般会推荐新手先从 Selenium 入手的原因：先跑通流程，再考虑优化速度。

2.3 目录结构长什么样

源码包解压后，目录大致是这样组织的：

damai_ticket/ ├── config/ │ └── settings.yaml # 账号、场次、票档、时间配置 ├── core/ │ ├── browser.py # 浏览器初始化与登录态加载 │ ├── scheduler.py # 定时任务与倒计时触发 │ └── order.py # 选场次、选票档、提交订单 ├── utils/ │ ├── logger.py # 日志记录 │ └── captcha.py # 验证码处理入口 ├── main.py # 入口文件 └── requirements.txt

这个结构的好处是配置和逻辑分离。你改抢票时间、换场次，只动config/settings.yaml；想换浏览器驱动，只动core/browser.py。二次开发时不用在几千行代码里翻找。

3. 跑起来的第一步：环境准备与配置填写

3.1 安装依赖与浏览器驱动

先确认本机有 Python 3.8 以上版本，然后进到项目根目录执行：

# 创建虚拟环境，避免污染全局包 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖 pip install -r requirements.txt

Selenium 需要浏览器驱动。Chrome 的话，下载对应版本的 chromedriver 放到系统 PATH 里，或者直接在browser.py里指定路径。常见做法是用webdriver_manager自动管理，但项目里没带这个依赖，所以手动配一次更稳妥。

提示：驱动版本必须和本机 Chrome 大版本一致，否则会报SessionNotCreatedException。

3.2 配置文件里哪些参数必须改

config/settings.yaml是唯一需要你手动填的地方。关键字段如下：

account: username: "your_phone" # 登录手机号 password: "your_password" # 登录密码，建议用环境变量注入 target: event_url: "https://..." # 演出详情页地址 session: "2025-01-01 19:30" # 场次时间，格式要和页面一致 price: "680" # 票档价格 quantity: 1 # 购买数量 timing: start_time: "2025-01-01 12:00:00" # 开票时间 advance_seconds: 2 # 提前几秒开始轮询 retry_interval: 0.5 # 重试间隔（秒）

advance_seconds这个参数很关键。设太大，请求发太早会被风控拦截；设太小，可能错过放票瞬间。我一般会设 1 到 2 秒，配合retry_interval做高频轮询。retry_interval不要低于 0.3 秒，否则容易触发限流。

3.3 启动脚本与首次运行观察

配置填好后，直接运行：

python main.py

首次运行建议把browser.py里的headless设为False，这样能看到浏览器实际操作过程。你会看到脚本自动打开页面、填充账号密码、点击登录。如果登录环节出现滑块验证，脚本会暂停，需要你手动完成一次。登录成功后，脚本会进入等待状态，直到start_time触发抢票逻辑。

注意：第一次跑不要直接等开票时间，先把start_time设成当前时间后两分钟，走一遍完整流程，确认每个环节都能正常跳转。

4. 核心模块拆解：登录态、定时触发与订单提交

4.1 登录态维持：cookie 复用与手动干预

登录是抢票的前置条件，也是最容易出问题的环节。项目里browser.py的做法是：首次运行手动登录，然后把 cookie 存到本地文件，后续运行直接加载 cookie 跳过登录。

# core/browser.py import pickle from selenium import webdriver def load_cookie(driver, cookie_path="cookies.pkl"): """加载本地 cookie，避免每次重复登录""" try: with open(cookie_path, "rb") as f: cookies = pickle.load(f) for cookie in cookies: # 部分 cookie 的 domain 字段需要去掉，否则 add_cookie 会报错 if "domain" in cookie: cookie.pop("domain") driver.add_cookie(cookie) return True except FileNotFoundError: return False def save_cookie(driver, cookie_path="cookies.pkl"): """登录成功后保存 cookie 到本地""" with open(cookie_path, "wb") as f: pickle.dump(driver.get_cookies(), f)

逻辑说明：load_cookie在每次启动时尝试读取本地 cookie 文件，如果存在就逐条注入到 driver 里。注意这里把domain字段去掉了，因为 Selenium 在某些版本下对 domain 校验很严格，不去掉会直接抛异常。save_cookie只在手动登录成功后调用一次。

参数方面，cookie_path可以改成任意路径，但建议放在项目根目录下，方便清理。cookie 有有效期，通常几天到几周不等，过期后需要重新手动登录一次。

4.2 定时触发：倒计时与轮询策略

scheduler.py负责在开票时间点触发抢票。核心逻辑是计算当前时间和目标时间的差值，然后进入轮询循环。

# core/scheduler.py import time from datetime import datetime def wait_until(target_time_str, advance_seconds=2): """等待到目标时间前 advance_seconds 秒""" target = datetime.strptime(target_time_str, "%Y-%m-%d %H:%M:%S") while True: now = datetime.now() delta = (target - now).total_seconds() if delta <= advance_seconds: break # 距离较远时降低检查频率，避免空转消耗 CPU time.sleep(min(delta - advance_seconds, 1)) return True def poll_order(order_func, interval=0.5, max_retry=20): """轮询提交订单，直到成功或达到最大重试次数""" for i in range(max_retry): result = order_func() if result: return True time.sleep(interval) return False

wait_until里有个细节：当距离目标时间还远时，time.sleep的时长会动态调整，避免每秒循环一次浪费资源。poll_order则是订单提交的重试包装，interval控制每次重试的间隔，max_retry防止无限循环。

这两个函数配合起来，就是“提前两秒开始，每 0.5 秒试一次，最多试 20 次”的抢票节奏。你可以根据自己网络状况调整interval，网络差就设大一点，但别超过 1 秒。

4.3 订单提交：选择器定位与异常捕获

order.py是最核心的模块，负责在页面上找到场次、票档、数量，然后点击提交。

# core/order.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def select_session(driver, session_text): """选择场次""" try: elem = WebDriverWait(driver, 5).until( EC.element_to_be_clickable((By.XPATH, f"//*[contains(text(), '{session_text}')]")) ) elem.click() return True except Exception as e: print(f"场次选择失败: {e}") return False def select_price(driver, price_text): """选择票档""" try: elem = WebDriverWait(driver, 5).until( EC.element_to_be_clickable((By.XPATH, f"//*[contains(text(), '{price_text}')]")) ) elem.click() return True except Exception as e: print(f"票档选择失败: {e}") return False def submit_order(driver): """点击提交订单按钮""" try: btn = WebDriverWait(driver, 3).until( EC.element_to_be_clickable((By.XPATH, "//*[contains(text(), '提交订单')]")) ) btn.click() return True except Exception as e: print(f"提交失败: {e}") return False

这里用 XPath 的contains(text())而不是精确匹配，是因为页面文本经常带空格或换行。WebDriverWait的超时设成 5 秒，给页面渲染留出缓冲。每个函数都包了 try-except，失败时返回 False，由外层poll_order决定是否重试。

实际运行时，select_session和select_price可能因为页面结构变化而失效。这时候需要你打开开发者工具，重新复制元素的 XPath 替换进去。这是 Selenium 方案最常见的维护点。

5. 避坑与排查：抢票脚本最容易翻车的五个地方

5.1 登录后立刻跳回登录页

现象：脚本填完账号密码点登录，页面刷新一下又回到登录页，cookie 没生效。

原因：多数是 cookie 注入时机不对。Selenium 要求先访问目标域名，才能add_cookie。如果直接开空白页就注入，cookie 会被丢弃。

解决：在load_cookie之前先执行driver.get("https://www.damai.cn")，等页面加载完再注入 cookie，最后再跳转到演出详情页。

5.2 开票瞬间请求被限流

现象：脚本在开票后疯狂重试，但每次返回“当前人数过多”或直接 403。

原因：retry_interval设得太小，比如 0.1 秒，请求频率超过平台阈值。

解决：把间隔调到 0.5 到 1 秒，并且在poll_order里加一个随机抖动，比如time.sleep(interval + random.uniform(0, 0.3))，让请求看起来不那么机械。

5.3 元素定位失效报 NoSuchElementException

现象：之前能跑的脚本，过几天再跑就报找不到元素。

原因：票务平台前端改版，class 名或 DOM 结构变了。

解决：不要依赖自动生成的 class 名，优先用文本内容或>import requests def notify(msg): webhook = "https://your-webhook-url" requests.post(webhook, json={"msgtype": "text", "text": {"content": msg}})

在submit_order成功之后调用notify("抢票成功，请尽快支付")，这样你不用一直盯着屏幕。

方向三：日志分级与回放。现在的logger.py只做了基础输出。建议加上 DEBUG 级别，把每次重试的响应时间、页面标题、当前 URL 都记下来。出问题的时候翻日志，比凭记忆复盘靠谱得多。我一般会在poll_order里加一行logger.debug(f"第{i}次重试，耗时{elapsed:.2f}s")，事后能清楚看到是哪次请求卡住了。

验证改造是否有效的方法：不要直接等真实开票时间。找一个已经开票但还有余票的演出，把start_time设成当前时间，跑一遍完整流程。如果能正常走到提交订单页，说明改造没破坏主链路。然后再把advance_seconds和retry_interval调回抢票参数。

最后说个血泪经验：我早期改这类脚本时，总喜欢一次性把超时、重试、通知全加上，结果某个环节报错导致整个流程静默失败，连日志都没打。从那以后我每次改完都强制走一遍“最小闭环”——只保留登录、选场次、提交三步，确认能跑通再往上叠功能。希望这个习惯也能帮到你。

本文还有配套的精品资源，点击获取