简介这是一份基于 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?id123456 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, headersheaders, timeout10) 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, datapayload, timeout10) 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] DescriptionTicketNotifier Afternetwork.target [Service] ExecStart/usr/bin/python3 /opt/ticket_notifier/main.py WorkingDirectory/opt/ticket_notifier Restartalways RestartSec10 [Install] WantedBymulti-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 分钟清空后台应用、养一个高等级账号、准备好全部观演人信息。这些准备工作听起来平淡但每一次都行得通。本文还有配套的精品资源点击获取