Python+DrissionPage多平台抢票脚本实战

简介面向演唱会及演出抢票场景的跨平台辅助脚本覆盖大麦网、淘票票、缤玩岛等多个票务渠道适合具备基础Python环境配置能力、希望减少手动刷新操作的票务用户。压缩包共19个文件体积约13.57MB主要包含Python主程序、浏览器自动化驱动、HTML确认页面、JSON配置数据以及多类工程文件其中XML和IML对应IDE项目配置MD与License用于说明使用步骤和开源条款EXE为驱动辅助可执行程序整体目录结构清晰便于按需取用。已有990人学习下载。脚本模块化程度较高将抢票主逻辑、场次票价配置、自动化驱动和确认页面分离用户可在JSON配置文件中灵活调整目标演出、票价档位等关键参数再配合自动提交与人工确认机制有效减少高峰期的重复点击与等待成本。对希望学习浏览器自动化与多平台票务脚本编写的开发者资源包中的工程目录、配置样例及说明文档提供了可对照修改的蓝本运行逻辑从读取配置到启动驱动、加载页面均有模块承接既保证实际可用性也保留了二次开发的余地。1. 项目背景与核心思路拆解先交代一下背景。前阵子为了看一场演唱会我在大麦网、淘票票、缤玩岛之间来回折腾手动刷新页面的手速根本跟不上放票节奏最后只好动手写了一套多平台抢票脚本。准确说这不是一个黑科技项目而是典型的“重复劳动自动化”问题放票那一刻大家拼的不是网速而是触发请求的时机和请求数量。脚本的作用就是把“盯时间、点按钮、选场次、勾选实名证人、提交订单”这一连串动作压缩到几百毫秒内完成。这套脚本解决的核心痛点是手工操作的滞后性。你眼睛看到“立即购买”按钮变亮手指再点下去至少需要300到500毫秒如果中途弹验证码、提示网络拥挤基本就凉了。而脚本可以在开票时间点精确到毫秒级发起请求同时用多重备选策略处理库存不足、占座失败等异常抢占下一个释放出来的票。适合谁看主要有两类人一类只是想提高自己抢票成功率的普通用户另一类是接手过类似自动化任务、想了解平台兼容性处理的开发者。无论哪种这套思路都适用。1.1 为什么手工拼不过机器拿大麦网举例它的一次完整抢票流程是进入详情页选场次、选票价档位、选数量然后点击“立即购买”等待页面进入确认订单页确认观演人和收货信息再点击提交订单。手动操作走完这一套少说要 5 秒而脚本只做两件事提前把页面元素都定位好到点直接触发事件提交订单时同时重试多个候选方案。这个差距不是手速能补的。另外票务平台通常不会在“开票”瞬间立刻把库存全部放出来而是分批发放。第一批被机器人或脚本抢完后不定期会掉落少量回流票。这就是为什么很多抢票脚本还带有“捡漏模式”每隔几百毫秒重新刷一次库存接口。我写这套脚本时也加入了捡漏循环实测对大连音乐节、成都蓉城主场球票这类热门演出捡漏成功率甚至比准点抢还高。1.2 技术选型我用的是“浏览器自动化接口辅助”混合方案一开始我只写了纯 requests 请求模拟直接调平台的订单接口。优点是快缺点是平台反爬很容易识别登录态、签名参数、加密字段一换脚本就废了。后来我改用“浏览器自动化接口辅助”的混合方案核心是 DrissionPage。DrissionPage 和 Selenium 类似但底层优化过不像 Selenium 那样容易被检测出 WebDriver 特征。为什么不用纯 Selenium因为大麦网、淘票票这样的人门级站点对 Selenium 的检测很成熟。Selenium 开启后浏览器指纹里会存在明显的自动化标识经常被要求滑块验证。DrissionPage 通过连接一个真实浏览器实例来操作相当于你人工在浏览器里敲击安全性高很多。核心思路是页面渲染、点击、验证码弹窗都用浏览器自动化解决库存查询和下单提交则用请求拦截的方式拿到加密接口地址再通过浏览器内部执行 JS 去调用两者结合既保证路径正确又降低被风控的概率。2. 核心细节解析与实操要点这类脚本的本质是“比正常用户更快完成标准操作流程”所以每一个环节都必须做到“可配置、可重试、可降级”。下面我把几个关键细节展开讲。2.1 登录态与账号准备无论哪个平台登录态都是第一道关。大麦的登录态是 Cookie 里的unb和loginInfo淘票票还要额外维护淘宝的登录态缤玩岛则是独立的手机号验证码登录。抢票脚本不建议每次现登录因为登录本身需要扫码或验证码会浪费时间。我的做法是提前用真实浏览器登录一次把 Cookie 保存到本地文件跑脚本时直接加载 Cookie如果失效再触发重新登录。保存 Cookie 的代码不复杂DrissionPage 会把浏览器实例的 Cookie 存成 JSON 格式恢复时重新注入。这里有个容易踩的坑Cookie 有有效期部分平台会做“滑动指纹”校验如果发现 Cookie 是在另一台设备上使用直接踢下线。所以尽量在要运行脚本的同一台电脑、同一个浏览器环境下登录并导出 Cookie。2.2 场次、价位、购票人的选择逻辑抢票前得把目标配置清楚要抢哪一场、哪个价位档、买几张、用什么实名证人。平台页面上场次和票价档位都是动态渲染的直接用固定 CSS 选择器不够稳最好按文本内容定位。比如大麦的场次按钮会有>pip install DrissionPage注意DrissionPage 的版本迭代很快有些类名和参数在不同版本间会变。我刚开始用旧文档里的DriverPage发现新版本已经改成ChromiumPage了导致脚本运行报错。建议安装完以后直接查看对应版本的官方文档别照搬网上的旧代码。另外需要安装一个 Chrome 浏览器DrissionPage 会复用当前浏览器环境所以浏览器版本不能太老我用的 Chrome 126 实测没问题。3.2 核心代码骨架整体项目结构是这样的ticket_script/ ├── main.py ├── config.py ├── platforms/ │ ├── __init__.py │ ├── base.py │ ├── damai.py │ ├── taopiaopiao.py │ └── binwandao.py └── utils/ ├── time_sync.py └── cookie_manager.pybase.py里定义了一个基础抢票类核心流程如下class BaseTicketBot: def __init__(self, config): self.browser ChromiumPage() self.config config self.cookies {} def load_cookie(self): # 读本地cookies文件注入浏览器 raise NotImplementedError def enter_event_page(self): # 进入演出详情页 raise NotImplementedError def select_area_and_date(self): # 选择场次和价位档 raise NotImplementedError def confirm_order(self): # 提交订单 raise NotImplementedError def run(self): self.load_cookie() self.enter_event_page() self.select_area_and_date() self.confirm_order()平台子类只需要实现每个方法里的具体选择器即可。这样有个很大的好处新接一个平台比如顺着热度接入成都蓉城主场的抢票只需要新写一个chengdu.py配置好页面元素几分钟就能跑。3.3 大麦网接入示例以大麦网页版详情页为例核心步骤是用文本定位场次和票价按钮def select_area_and_date(self): area self.browser.ele(xpath://div[contains(text(), 2025-07-12)]/ancestor::button) area.click() price self.browser.ele(xpath://div[contains(text(), 看台388)]/ancestor::button) price.click()注意这里的ele方法会优先等待页面元素出现默认超时是 10 秒。如果目标按钮没抢到变成灰色不可点击click()会抛异常需要在异常里做降级处理。我通常用try/except捕获捕获后直接尝试次选价位。提交订单的瞬间是最容易失败的代码里要对“参数缺失”做额外判断比如购票人没有选中实际点击“提交订单”按钮后发现页面弹“请选择观演人”。这可以通过点击后立刻检查弹窗文本处理如果出现“观演人”关键词就重新勾选再提交。3.4 淘票票、缤玩岛的多平台适配淘票票和大麦整体流程类似但淘票票是嵌在淘宝体系里的登录态判断更复杂。我在taopiaopiao.py里直接复用淘宝的 Cookie 管理但要注意淘票票部分页面引入了一组叫mtop的请求签名参数纯浏览器自动化不受影响但如果用请求拦截就得同步解析页面里的 token。这算是最容易出问题的点。缤玩岛相对小众页面结构更简单主流程就是列表页选时间、详情页点赞、加入购物车、结算。但这个平台的支付步骤有单独的一次性短信确认所以脚本不能只到“下单成功”就结束还需要监听短信验证码的输入框提示用户手动填一下。我在缤玩岛的脚本里特意加了一个wait_for_sms_code()的步骤弹窗用系统通知提醒否则很容易出现“下单成功但支付超时”的尴尬。3.5 成都蓉城抢票脚本的实战套壳自从成都蓉城主场球赛火起来以后很多朋友都来问这脚本能不能抢球票。其实逻辑完全一样球票主办方也有固定的放票时间和库存但球票和演唱会相比场次少、价位固定、实时座位图多所以不能只按价位选择还得支持选区。这里我的做法是在基础类里增加一个select_zone()方法默认返回空成都蓉城平台的子类就重写这个方法按区块名定位比如“东区看台”“西区看台”。对这套配置我做了个简化版命令行参数python main.py --platform chengdu --date 2025-08-02 --zone 东区看台 --num 2亲测下来只要提前把 Cookie 和实名信息弄好开票时能稳定进入选择器和订单页剩余的就是验证码和手速的问题了。4. 常见问题与排查技巧实录以下问题都是我实际测试时踩过的坑整理成速查表方便你直接对照。现象原因解决办法开票前一秒还能打开详情页开票瞬间白屏页面被临时重定向或静态资源卡住启用浏览器多标签页提前加载详情页开票时切到已加载完成的标签反复提示需要登录Cookie 被识别或过期清空本地 Cookie用真实浏览器重新扫码登录并导出新版 Cookie点击购买后一直转圈提交订单请求被拦截或参数缺失打开浏览器开发者工具看请求返回的状态码检查购票人是否勾选用 Selenium 总是弹验证码WebDriver 特征太明显换成 DrissionPage或者让脚本把验证码滑块界面弹出来人工处理多账号同时抢票导致所有账号被风控同 IP 并发过多限制为单账号单线程或使用代理 IP 做账号隔离不过这个成本较高4.1 被风控或验证码拦截这是最常见的问题。我见过最狠的一次是大麦网开票前突然升级风控所有脚本一律跳滑块验证页面 5 秒内不操作就自动关闭。解决办法有两个一是降低脚本的操作频率不要每 100ms 就去点击同一个按钮改成 300ms二是给脚本增加“人类行为模拟”比如在进入详情页前随机停顿几百毫秒鼠标轨迹也随机一点。虽然没法完全绕过但至少能降低触发概率。4.2 Cookie 失效与登录态丢失Cookie 失效大多发生在跨天、跨地域或者改了密码之后。我的经验是每次脚本启动前先访问平台首页判断是否还处于登录状态。如果页面右上角没有头像或者昵称就触发微信扫码登录或手机验证码。有些脚本直接用 requests 的 session 模拟Cookie 一旦失效整个 session 就废了重启浏览器恢复活不过来。4.3 提交订单后一直转圈这种情况常见于大麦提交订单时如果浏览器请求头里的Referer字段不对平台会一直卡在“处理中”。很多人只检查代码逻辑忽略了浏览器上下文环境。我把这个坑修复后成功率提升了一大截。具体来说就是在确认订单页、点击提交按钮前从浏览器上下文读取当前页面 URL作为后续请求的 Referer不要硬编码。4.4 多线程抢票引发的问题抢票脚本最忌讳多线程同时去点同一个按钮这不是增加成功率而是增加风控概率。正确做法是单线程内多次请求或者多个账号顺序执行。如果你真想同时抢多个账号建议在不同设备或虚拟机里运行各用各的浏览器环境。我早期在一台电脑上开了三个账号同时抢结果三个账号全部被要求重新登录损失惨重。5. 这套脚本还能怎么扩展核心框架调通之后后面就是怎么让它更好用的问题了。5.1 接入消息通知抢票结果不必一直盯屏幕。我接了 Server 酱和 Bark 两个通知渠道脚本一旦下单成功立刻通过手机推送提醒“订单提交成功请在 15 分钟内完成支付”。这样即使家里没人也能及时收到消息用手机付款。import requests def send_notify(title, content): requests.get(fhttps://api.day.app/YOUR_BARK_KEY/{title}/{content})5.2 定时任务与云端运行脚本本地跑有一个问题电脑不能休眠网络要稳定。我后来把它挪到了云服务器上用cron定时触发浏览器用 Headless 模式。这里有个坑Headless 模式对大麦网的支持不稳定部分页面在无头模式下拿不到完整 DOM。最终我把无头模式关掉用 Xvfb 虚拟屏幕运行稳定很多。5.3 多平台配置化如果你不介意改代码可以把每个平台的选择器、地址、开票时间都写成 JSON 配置这样不用改代码就能适配新演出。我自己的config.json长这样{ platform: damai, event_url: https://detail.damai.cn/item.htm?idxxx, target_date: 2025-07-12, target_price: [看台388, 看台588], buyer_num: 2, retry_interval: 0.2 }这种配置方式让脚本的门槛降低很多哪怕是完全不懂代码的人只要会改 JSON也能完成基本操作。最后再分享一个小经验无论脚本写得再好头一晚一定要去目标演出页做一次“彩排”把浏览器环境、Cookie、实名信息全部跑通。我就有一次没彩排第二天抢的演出是站席页面根本没有“座位图”选项脚本卡在选座步骤白白错过放票。抢票脚本不是替代你思考只是把你有把握的操作加速执行。把基础准备工作做扎实成功率自然就上来了。本文还有配套的精品资源点击获取