简介：这是一份基于 Python 和大麦网官方网页实现的自动化抢票脚本，主要面向有 Python 基础、希望借助 Selenium 完成在线抢票或学习网页自动化的开发者。脚本以 Chrome 浏览器驱动为依托，通过 config.json 灵活配置场次优先级、票价档位、实名者序号、购票数量及登录昵称，能够按用户设定的顺序尝试提交订单，有效减少手动刷新与重复操作。资源共 29 个文件，主要包含 Python 主脚本、JSON 配置文件、Markdown 说明文档以及 Git 版本库相关元数据，整体压缩包仅 51KB，结构轻量，便于快速部署与二次修改。目前已有 5072 人学习下载，反馈不错。通过这份资料，读者可拿到完整可运行的抢票脚本、配置方法说明及基于 Selenium 的自动化操作思路，既适合大麦网购票场景中提升下单效率，也可作为 Python 自动化测试与网页交互的实战入门案例。
抢票脚本这事，我劝你先想清楚再动手
每年一到热门演唱会开票，朋友圈里就会冒出好几个来问我"有没有大麦抢票脚本"的朋友。作为一个常年写 Python 自动化的开发者，我太理解这种心态了——手速拼不过别人、验证码点到手抽筋、页面刷新到崩溃，最后只换来一个"已售罄"的页面。这时候谁不想要一个能自动下单的工具？
但我给不了。不是写不出来，而是这个东西的边界非常微妙：它游走在"优化用户体验"和"绕过平台安全机制"之间，稍一越界就是违反服务协议甚至涉嫌违法。这篇文章我会把抢票脚本背后的技术原理、票务平台的反制手段，以及真正合规的自动化写法都讲清楚。文章最后附一个我自己用的余票监控和提醒工具，它不破解验证码、不伪造请求、不绕风控，只是帮你把"盯票"这件事自动化，剩下的还得靠你自己手速和运气。
1. 抢票脚本这个需求，是怎么火起来的
1.1 热门演出场景下的"一票难求"
大麦、猫眼、秀动这些票务平台，平时买票没什么难度，可一到热门演出就是另一个世界。周杰伦、薛之谦、五月天，开票几秒钟内全部售罄。官方售票页面上明明白白写着"缺货登记"，二手平台上同场次的票却能挂出两三倍的价格。
这背后的供需失衡非常严重：一场演唱会的可售票量是固定的，但想买的人可能是票量的几十倍甚至上百倍。在"手快有、手慢无"的规则下，任何能让人"手更快"的工具都有了市场。Python 脚本出现在这里并不奇怪，因为 Python 做网络请求、页面解析、定时任务都太方便了，十几行代码就能实现一个轮询器。
1.2 Python 为什么总被拿来干这件事
我最早接触这类需求是在一个开源社区。有开发者写了一个"演唱会余票监控"的小工具，原理非常简单：每隔一段时间去请求一次票务平台的余票查询接口，一旦发现有余票就立刻弹窗提醒。这个工具当时口碑很好，因为它没有替用户自动下单，只是解决了"人工反复刷新页面"这个痛点。
后来市面上出现的"抢票脚本"就慢慢变味了。它们开始做这几件事：自动识别验证码、模拟完整下单流程、多线程高频请求、甚至动态切换 IP 绕过限流。这些手段已经不属于"辅助人工"，而是直接用程序替代了"抢票"这个动作的绝大部分环节。平台的风控系统当然不会坐视不管，于是两边就开始了一场漫长的军备竞赛。
我的建议是：你可以对技术原理保持好奇，但如果你真想把它用在购票上，请先搞清楚你正在触碰的是哪条线。
2. 票务平台的反抢票机制到底在防什么
想要理解一个自动化工具能做和不能做什么，得先知道对面在防你什么。票务平台的防御体系大致分两层：前端人机验证和后端风控。
2.1 前端的人机校验与指纹识别
你打开大麦的页面，看到的需要滑动拼图、点选文字、识别图库的验证码，属于前端人机校验。这些验证码的作用是在下单前证明"你是一个人类"。由于验证码本身是由第三方服务提供的，识别难度可以根据风控等级动态调整——普通用户看到的是简单拼图，被判定为"高风险"的会话看到的可能就是复杂点选。
前端还有一层是浏览器指纹识别。平台会采集你的 User-Agent、Canvas 指纹、WebGL 信息、屏幕分辨率、浏览器插件列表等大量特征，组合成一个唯一的"设备指纹"。如果你用同一个浏览器反复切换账号，或者用无头浏览器伪装正常访问，指纹层面的异常会第一时间被标记。这也是为什么很多"抢票脚本"跑着跑着突然就"掉线"了——不是网络问题，是你的指纹已经进了黑名单。
2.2 后端的风控模型与限流策略
后端风控负责发现"非人类行为模式"。举个例子，正常人下单前的操作路径可能是：搜索 → 浏览详情 → 选场次 → 选座位 → 提交订单，每步之间至少有几秒甚至几十秒的思考时间。脚本的路径则是：直接请求购票接口 → 立刻提交，整个流程耗时不到 200 毫秒。这种"瞬移式"操作在风控模型眼里非常刺眼。
限流策略则是另一道防线：单个 IP 的请求频率限制、单个账号的购票频率限制、单台设备的会话数限制。一旦触发，轻则要求二次验证，重则直接封禁账号。这些策略通常是黑盒的，平台不会公开具体阈值，但开发者可以通过观察请求响应来推测。比如某平台的余票查询接口，一个 IP 一分钟内请求超过 60 次就会返回 403。这些信息都是无数人踩坑踩出来的，没有公开文档可查。
理解了这套机制，你就应该明白：一个"合规的自动化工具"应该是那些不伪装人类、不高速轰炸、不触发风控的辅助工具。而市面上流传的大部分抢票脚本，本质上都在和这套机制正面硬刚。
3. 从"抢票脚本"到"合规自动化"：三个正当方向
如果你想用 Python 提升抢票成功率，我强烈建议把思路从"绕过风控"转向"优化流程"。下面这三个方向我都实测过，完全合规，不会被封号，而且确实能减少你的重复劳动。
3.1 使用官方API与开放接口
很多票务平台提供公开的演出信息查询接口，比如获取演出详情、场次列表、价格区间这类数据。这类接口本身就是给前端页面用的，你不过是换了一种方式去访问同一个数据源，本质上和浏览器打开页面没区别。只要请求频率控制在合理范围，根本不会触发风控。
我见过很多人一上来就抓包找下单接口，其实完全没必要。先看看目标平台有没有开放接口、有没有开发者文档。即便只有信息查询类接口，也足够做出一款好用的"开票提醒"工具了——与其天天刷新页面，不如让程序盯着接口，一旦有新演出上架或者票档开售，立刻通知你。
3.2 做一款不越界的余票提醒器
这是我把控的安全边界最清晰的一个方向。一个余票提醒器做三件事：按固定间隔查询余票状态、判断状态是否有变化、有变化时推送通知到你的手机。它不填写手机号、不提交订单、不做任何需要登录才能完成的动作，只是把"偷看"这一步自动化了。
这样做有两个好处：一是不会违反服务协议的实质性条款，因为你没有影响平台正常运营，也没有对他人的购票机会造成威胁；二是开发难度低，基本只涉及 HTTP 请求、JSON 解析和消息推送，两个周末就能搞定。
3.3 用自动化提升"人肉抢票"的手速
很多人忽略了最简单的优化方向：把开票前的准备工作做到极致。比如抢票前十分钟提前进入页面、提前选好场次并填写好观演人信息、确保网络环境稳定、关掉所有占用带宽的应用。这些看似基础的操作，实际上比任何脚本都更能提升成功率。
我还可以告诉你一个小技巧：很多平台的支付环节是有时限的（比如 15 分钟内必须完成支付），所以每隔几分钟就会有一批"未支付释放"的余票回流。这时候你没有脚本、只有手速，能不能捡漏就看你有没有一直盯着页面。而这个场景恰好是余票提醒器的用武之地——它会第一时间通知你"有票了"，然后你再手动操作。虽然不能保证抢到，但至少你不用傻傻刷一整天。
4. 手写一个余票监控与通知小工具（不碰风控边界）
这部分我分享一个我自己在用的脚本，它的名字叫 "TicketNotifier"，功能非常简单：轮询一个公开的演出信息接口，当目标场次的票档状态从"缺货"变为"可售"时，给我推送一条微信通知。整个代码不涉及登录态、不涉及验证码、不涉及下单接口，完全在合规范围内。
4.1 环境准备与请求库选型
先交代一下环境：Python 3.9+，依赖库用requests和schedule。你可能好奇为什么不用异步框架，原因很简单——脚本的轮询间隔通常设置在 30 秒到 60 秒，这个频率下同步请求完全够用，没必要引入 asyncio 或者 aiohttp 增加复杂度。考虑到后续可能部署在低配服务器上，依赖越少越好。
pip install requests schedulePython 的安装我就不多说了，建议直接用官网的安装包，装完记得勾选 "Add Python to PATH"。
4.2 分析公开页面的数据接口
打开目标票务平台某场演出的详情页，按 F12 进入开发者工具，切到 Network 面板，刷新页面。你会看到一堆请求，其中有一个名字类似于detail.json或者getPerformances的接口，返回的是 JSON 格式，里面包含了演出名、场次列表、票档余量等数据。这个接口就是我们要轮询的对象。
不同平台的接口结构不一样，我这里用一段脱敏后的示例来说明。假设我们拿到一个返回如下结构的接口：
{ "code": 0, "data": { "showId": 123456, "name": "某某演唱会-北京站", "performances": [ { "performanceId": 888888, "time": "2025-05-01 19:30", "priceLevels": [ {"price": 580, "status": "sold_out"}, {"price": 880, "status": "on_sale"} ] } ] } }注意priceLevels里的status字段，我们关心的就是它从sold_out变为on_sale的那个瞬间。
4.3 实现轮询、状态判断与通知推送
核心代码分成三块：请求数据、解析状态、发送通知。请求和解析都很常规，重点说说通知这块。我用的方案是 Server酱（sct.ftqq.com），它提供一个 HTTP 接口，你把消息 POST 过去，它就会通过微信服务号推送到你的手机上。免费额度足够个人使用，而且不用开发手机 App。
import requests import time import hashlib # 配置区 CHECK_URL = "https://api.example.com/show/detail?id=123456" NOTIFY_URL = "https://sctapi.ftqq.com/YOUR_SENDKEY.send" TARGET_PRICE = 880 # 盯的目标票档价格 CHECK_INTERVAL = 30 # 轮询间隔（秒） headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://example.com/" } # 记录上一次的状态，只有状态变化时才推送 last_status = {} def check_status(): global last_status try: resp = requests.get(CHECK_URL, headers=headers, timeout=10) resp.raise_for_status() data = resp.json() performances = data["data"]["performances"] changed = False message_lines = [] for perf in performances: for pl in perf["priceLevels"]: if pl["price"] == TARGET_PRICE: current = pl["status"] key = f'{perf["performanceId"]}_{pl["price"]}' if last_status.get(key) is None: last_status[key] = current elif last_status[key] != current: changed = True message_lines.append(f'{perf["time"]} {pl["price"]}档状态变化：{last_status[key]} -> {current}') last_status[key] = current if changed: send_notification("\n".join(message_lines)) except requests.RequestException as e: # 单次请求失败不致命，打印日志即可 print(f"[{time.strftime('%H:%M:%S')}] 请求异常: {e}") def send_notification(message): payload = {"title": "余票状态变化", "desp": message} try: resp = requests.post(NOTIFY_URL, data=payload, timeout=10) print(f"[{time.strftime('%H:%M:%S')}] 通知推送结果: {resp.text[:200]}") except requests.RequestException as e: print(f"通知推送失败: {e}") if __name__ == "__main__": print("TicketNotifier 启动，轮询间隔 {} 秒".format(CHECK_INTERVAL)) while True: check_status() time.sleep(CHECK_INTERVAL)这里有几个细节值得展开说。
首先是last_status这个字典的作用。如果每次轮询都推送，你会在开票当天收到几十条"仍无票"的垃圾通知。我们只在状态真正变化时才推送，这个去重逻辑非常关键，能避免你再写一套消息频率控制。
其次是请求方式。我特意在 headers 里带了User-Agent和Referer，不是要伪装成浏览器，而是很多接口会校验 Referer，不带可能直接拒绝服务。你也可以复制浏览器里实际的 User-Agent，这样更保险。
最后是异常处理。网络请求丢包、超时、接口短暂不可用都是常态，不要让脚本因为一次异常就崩溃。打印日志后继续下一轮，这才是稳定运行的正确姿势。
4.4 部署到服务器或家里的NAS
脚本本地跑没问题，但你不能一直开着电脑，所以建议扔到一台 7x24 小时在线的设备上。家里有 NAS 的可以直接用 Docker 跑，没有的话腾讯云、阿里云买台最便宜的轻量服务器也够了，这种脚本消耗资源极小，1 核 512MB 内存的机器跑起来毫无压力。
Linux 服务器上我推荐用 systemd 管理脚本进程，比 nohup 好用得多，支持开机自启和崩溃自动重启。写一个 service 文件：
[Unit] Description=TicketNotifier After=network.target [Service] ExecStart=/usr/bin/python3 /opt/ticket_notifier/main.py WorkingDirectory=/opt/ticket_notifier Restart=always RestartSec=10 [Install] WantedBy=multi-user.target保存到/etc/systemd/system/ticket-notifier.service，然后执行：
systemctl daemon-reload systemctl enable ticket-notifier systemctl start ticket-notifier以后查看日志就用journalctl -u ticket-notifier -f，是不是比 nohup 优雅多了。
5. 踩坑记录与性能优化
这个工具我用了大半年，踩过不少坑，简单分享几个比较典型的，帮大家少走弯路。
5.1 高频轮询被限流的处理
最开始我把轮询间隔设成 5 秒，结果跑了不到十分钟，接口直接开始返回 403。后来我把间隔逐步调大，发现 15 秒以上基本不会触发限流，但为了稳妥起见，最终定在 30 秒。做这类轮询工具，一定要记住一个原则：频率越低越安全。票档状态的变化通常不是一秒两秒内发生的，30 秒的延迟对"捡漏"场景来说完全够用。
如果确实觉得 30 秒太慢，可以用多个账号跑多个实例，但每个实例的间隔不要低于 15 秒。千万别在同一个 IP 上并发跑几十个实例，那基本等于自投罗网。
5.2 请求状态码与页面结构变化
某次大版本更新后，目标接口突然返回 200 但 JSON 结构变了，priceLevels直接挪到了别的层级。我脚本里没做严格的结构校验，导致keyError直接把进程打崩了。吃了这次亏之后，我重构了解析逻辑，加了一个兜底：如果连续 3 次解析失败，就推送一条"页面结构可能变化"的告警给我自己，而不是无声无息地挂掉。
另外建议在每次请求时带上Accept-Encoding: gzip，有些接口压缩后响应体积能缩小 80%，对弱网环境下的稳定性有帮助。不过这个是锦上添花，不是必需。
5.3 通知消息的频控与去重
还有一个容易忽略的坑：Server酱这类免费推送服务通常有频率限制，一分钟内超过次数会直接丢弃消息。如果开票瞬间多个票档同时变化，你的脚本可能一口气把额度打满，后面的推送全部失败。
解决办法是在推送之前做一个简单合并：把同一次轮询里检测到的所有变化合并成一条消息发送，而不是一个变化发一条。我的代码里已经用了message_lines这个列表做合并，你可以在这个基础上再加一个"同类消息 10 分钟内只推一次"的缓存，效果会更好。
6. 给想靠脚本抢票的人算一笔账
6.1 技术对抗的军备竞赛
如果你仍然想走"抢票脚本"这条路，我劝你先看看对面是什么级别的对手。票务平台的风控团队不是一个程序员在单打独斗，他们有专门的反爬虫小组、风控算法工程师、第三方验证码服务商，甚至在每年大促前会做专门的攻防演练。你的脚本从写出来到被识别，可能只需要几天时间。之后你就要不断升级验证码识别策略、更换 IP 池、调整请求参数，忙活一整年，最后大概率还是抢不过人家的"内部通道"。
这不是我在泼冷水，而是所有圈内做自动化的人都会告诉你的现实：永久有效的抢票脚本是不存在的，它只是你和风控系统之间的猫鼠游戏。你付出的时间成本、服务器成本、无限的精神内耗，最终只会让你离"轻松看一场演唱会"这个目标越来越远。
6.2 账号封禁与法律风险
再退一步，就算你的脚本跑通了，法律风险也摆在那里。票务平台的用户协议里通常会明确禁止使用自动化程序访问或购买票务。违反协议最直接的后果是账号封禁，你辛苦养了多年的账号等级、会员权益可能一夜清零。如果你的脚本伪造请求、绕过验证码、篡改接口数据，还可能违反网络安全相关法规里关于"侵入、非法控制计算机信息系统"的条款。这些后果，不是一个票价能换回来的。
最让我无语的是，很多人花了几百块去买网上的现成脚本，用几天账号被封了，去找卖家退款才发现对方早就跑路了。这种脚本通常还留有后门，你输入的手机号、身份证信息全被收集走了，甚至可能用你的账号做二次分发。这笔账怎么算都是亏的。
6.3 技术热情应该用来做更持久的事
坦白说，我理解大家对自动化技术的热情，我自己也是从写各种小脚本入门的。但技术热情应该有更持久的落点：把轮询、事件通知、状态机这些思路用在开源社区、个人效率工具、数据分析上，能创造出比"抢一张门票"大得多的价值。
我现在做的这个余票监控工具就是一个例证：它用了网络请求、数据解析、消息推送这些跟"抢票脚本"一模一样的核心技术，但它不越界、不坑害他人，还能让我在凌晨三点发现回流票时兴奋地从床上跳起来。这种"技术改变了生活"的感觉，才是我想在这个行业里一直保持下去的动力。
最后再分享一个小技巧：如果你真的想提升抢票成功率，与其折腾脚本，不如把开票时间定上闹钟、提前 10 分钟清空后台应用、养一个高等级账号、准备好全部观演人信息。这些准备工作听起来平淡，但每一次都行得通。
本文还有配套的精品资源，点击获取
