简介面向大麦平台演出票抢购用户这套自动化脚本基于Selenium打开浏览器完成登录并模拟真实购票流程适合有一定Python基础、想摆脱手动刷新和排队等待的读者。压缩包共18个文件大小约1.08MB核心为8个py源码文件配套json参数配置、txt说明、png示例图以及drawio流程图另附移动端Appium自动化目录能帮助延伸了解移动端抢票方案按目录即可快速定位登录、选场、下单等模块。资源已有6195人学习下载作者标注已有大佬验证可以成功。拿到后可先阅读说明和配置示例完成环境搭建再依据自身账号与目标场次调整参数运行同时能学习Selenium页面元素定位、浏览器事件模拟、配置文件读取等实战技巧并借助可编辑流程图理解整体抢票链路省去从零摸索的成本二次开发门槛较低。1. 抢票脚本不是玄学一场与风控系统的攻防网上流传的抢票脚本总喜欢强调一句“已有大佬验证可以成功”好像拿到代码就等于拿到了票。但以我接触这类自动化方案的经验看凡是把抢票脚本当成“双击就能跑”的项目最后基本都卡在验证码和接口风控上。这个标题真正指的事情是把浏览器里一次点击背后的抢票动作拆成登录、查场次、提交订单这几个接口调用再由程序在开售那一瞬间发出请求。它能解决的是“手动点太慢、每次都卡在选座和提交之间”的问题适合的读者是被抢票折磨过、懂一点抓包和编程、想把整个链路弄明白的人。往下读之前先想清楚一件事脚本的价值不在于代码本身而在于你知不知道自己在跟什么样的风控系统打交道。2. 抢票链路拆解一次点击背后的五次请求与四个风控关口先看点发生在“点击购票”之后的事。你在网页上点一次按钮浏览器里实际发生的动作有五六次页面先拉取当前场次列表确认哪些场次还有票然后读取你选中的票价档位与库存状态接着校验当前登录账号的实名信息再往后才是提交订单最后创建订单并跳转支付。每一个步骤都对应一个HTTP接口这几个接口之间的先后顺序决定了脚本的骨架。如果对这个骨架没有概念后面写代码就只能靠猜。2.1 一次点击背后的五次请求为什么脚本要动接口而不是模拟点击很多人问过“直接用模拟点击的RPA工具把鼠标键盘录下来重放不行吗”答案是不行。第一网页端DOM每次改版都会变上周能识别的按钮位置这周就换了一整套类名第二模拟点击有肉眼可感知的延迟这里慢几百毫秒在抢票场景里就是天壤之别第三平台行为检测模块最容易识别的就是机械鼠标轨迹和固定间隔点击。所以正常做法是动接口用抓包把票务页这几次请求拿下来再用脚本直接发HTTP请求。这样延迟可以压到几十毫秒级别也不会因为DOM变化而重写整个脚本。要拿到这几次请求常规做法是在电脑上开一个带抓包配置的调试通道手机端把网络指向它然后手动完成一次购票流程。这里有一个容易被忽略的细节先手动买一次不是为了测试而是为了拿到一份“能成功下单的请求样本”。之后所有参数对齐都以这份样本为准。为什么提交订单和创建订单是两个接口而不是一个这是票务系统的通用设计。提交订单负责校验库存、实名信息和票档规则校验通过后服务端会生成一个订单token并锁定库存创建订单再拿着这个token完成落单。脚本最容易搞错的地方就是把这两个接口当成一次请求处理结果token还没拿到就急着创建订单。理解请求之间的依赖关系比多写几行代码重要得多。2.2 影响抢票成败的四个风控关口把抢票链路拆开之后你会发现真正的难点并不在“会不会发请求”而在于怎么越过这几个风控关口。关口检测维度常见触发条件账号状态实名信息、账号活跃度、历史订单新注册账号、换绑手机、频繁登录设备指纹User-Agent、Canvas、WebGL、字体列表无头浏览器、固定UA、缓存被清请求频率固定时间窗内请求数量1秒内多次提交订单、持续高频轮询下单速度服务器时间对齐、库存扣减顺序本地时钟偏慢、没有预填常用观演人这四个口每个都有一票否决权。账号状态是基础门槛平台判断你像不像真实用户设备指纹决定了你这次访问的“物理身份”请求频率是实时熔断短时间内动太快直接拒绝下单速度才是大家讨论的“手速”。市面上那些声称“成功”的脚本并不是四个口都能过更多是恰好碰到风控策略比较松的场次。这四个关口之间还有联动关系。账号在异常设备上登录会拉低账号状态评分账号分数低了请求频率的阈值也跟着降低频率一高又触发滑块。这就是为什么有些人只改一个参数反而越改越糟。抢票脚本实质上是一个排队系统你在跟成千上万个请求同时抢一个库存扣减机会。脚本能做的是保证请求规范、时序正确、速度够快但没法让平台为它开后门。认清这一点后面遇到失败就不会盲目怀疑代码。3. 用 Python 搭一个最小抢票脚本从抓包到会话保持这一章开始动手。我讲一个最简但能跑通日常预约场景的方案用Python的requests库保持登录态轮询场次状态在开售时间点发起下单请求。这套结构不依赖任何第三方抢票框架自己维护起来也容易排查问题。3.1 抓包定位下单链路用抓包工具列出一张接口清单先列接口清单不然写代码没有依据。我一般会按“登录 → 查场次 → 查库存 → 提交订单 → 创建订单”的顺序整理一份表格记下每个接口的请求方式、关键参数和返回结构。阶段接口示意方法关键参数登录/auth/loginPOSTusername, password场次列表/show/listGETcity, page库存状态/show/stockGETshowId, priceId提交订单/order/submitPOSTshowId, priceId, userId创建订单/order/createPOSTorderToken抓包这一步有四个注意点。第一手机或浏览器代理配置好后先访问一次首页确认抓包工具能解开HTTPS流量不然看到的全是加密乱码。第二手动走完整个购票流程不要中途退出因为有些接口只在最后一步才会调用。第三重点找那个返回订单token的响应它往往在提交订单接口里。第四如果页面用了WebSocket推送库存状态还要额外记录消息格式。这份清单不需要把每个字段都搞清楚但三个东西必须确认提交订单接口的入参格式、创建订单接口依赖的token来源、下单接口的请求头。很多脚本翻车就是因为“提交订单”和“创建订单”用了两套不同的请求头导致服务端校验不通过。3.2 登录与会话保持的完整代码围绕这份清单先写会话层。为什么单独做一层因为票务平台登录成功后下发的cookie和token后续所有请求都要带。如果每个接口各写各的一旦token过期排查成本会翻倍。import requests import time from fake_useragent import UserAgent class TicketClient: 最小会话客户端负责登录态和通用请求头 def __init__(self, timeout5): self.session requests.Session() self.timeout timeout ua UserAgent() self.session.headers { # 固定UA不要每次请求随机变化否则容易被风控盯上 User-Agent: ua.chrome, Accept: application/json, text/plain, */*, Content-Type: application/json;charsetUTF-8, Referer: https://ticket.example.com/ } def login(self, username: str, password: str) - bool: 模拟登录真实平台多为扫码或短信验证这里用账号密码做最小示意 login_url https://api.example.com/auth/login payload { username: username, password: password, source: web } resp self.session.post(login_url, jsonpayload, timeoutself.timeout) data resp.json() if data.get(code) 0: # 登录成功后把token放进公共请求头 self.session.headers[Authorization] Bearer data[data][token] return True return False def get_show_list(self, city_id: str) - list: 获取场次列表开售前用低频轮询判断可售状态 url https://api.example.com/show/list params {city: city_id, page: 1, pageSize: 50} resp self.session.get(url, paramsparams, timeoutself.timeout) return resp.json().get(data, {}).get(list, [])这段代码有三个参数值得细说。超时时间timeout我习惯设成5秒超过就直接抛异常避免下单阶段卡死在一个请求上User-Agent用fake_useragent生成一次然后固定是因为如果每次请求UA都不一样风控设备指纹里会留下“UA频繁漂移”的记录Referer字段很多人会漏掉但它是服务端校验来源是否合法的低成本手段必须和浏览器抓包结果保持一致。cookie保持由requests.Session自动处理登录接口返回的Set-Cookie会写进会话后续请求不用手动维护。3.3 定时触发下单请求同步服务器时间比提前循环更重要抢票成败有一个常被忽略的因素本地电脑时钟和服务器时钟不一致。你本地显示10点整时服务器可能已经过去了一秒半。所以脚本的第一件事不是发请求而是校准时间。def get_server_time(client: TicketClient) - float: 从服务器取时间戳计算本地与服务器的时间偏移量 url https://api.example.com/time resp client.session.get(url, timeout3) server_ts float(resp.json()[data][serverTime]) / 1000.0 local_ts time.time() return server_ts - local_ts拿到这个offset之后脚本里所有时间判断都以“本地时间 offset”为准。开售点提前量怎么设我看过很多人喜欢提前500毫秒循环发请求结果就是被频率风控标记。我的习惯是提前量设在300毫秒只发一次请求失败后按100毫秒、300毫秒、700毫秒的间隔做三次退避重试。这个参数的依据是开售瞬间库存释放和扣减有一定缓冲太早请求会被当成探测太晚又排到队尾。重试时还要判断返回码只有库存不足或人流过大才值得重试如果是签名失效或账号异常重试多少次都没有意义。4. 抢票脚本真正的两座山接口签名与滑块轨迹识别requests能解决的只是请求层问题。当你把最小脚本跑通准备对付热门场次时会撞上两座山接口签名和滑块验证。这两道坎过滤掉了大多数人。4.1 接口签名从固定口令到动态 token不少票务平台的订单接口都带一个名为sign的动态参数。它的生成逻辑通常是把请求参数按字典序排序拼上时间戳和一个固定密钥再做HmacSHA256哈希。表面上看并不难但实际平台的JS代码会做多层混淆参数名也可能是动态生成的。下面是这类签名的生成思路便于理解。import hashlib import hmac def generate_sign(params: dict, secret: str) - str: # 参数按key排序拼成 kvkv 形式 raw .join(f{k}{params[k]} for k in sorted(params)) raw secret secret # 大多数平台用HmacSHA256也有用MD5或SHA1的 return hmac.new(secret.encode(), raw.encode(), hashlib.sha256).hexdigest()这个函数的关键在于“排序后的拼接顺序”和“密钥来源”两者都需要从抓包样本里推。我见过有人把sign当固定值写死在脚本里结果平台加了时间戳校验一旦超过有效时间直接返回签名失效。处理这种接口正确路径是去抓包JS里找生成函数断点调试出参数拼装规则然后在Python里复刻。这个过程比较枯燥但也绕不开。一个可用的排查技巧是在浏览器里修改某个请求参数观察sign是否变化、变化发生在哪一段。如果参数A变了sign没变说明A没有参与签名如果变了就把A追加到参数字典里再排序。反复几次签名范围就摸清了。4.2 滑块识别为什么你的脚本在这里翻车滑块是另一座山。很多抢票脚本辛辛苦苦搞定签名却在滑块上消耗了大量时间。滑块验证的核心不是判断你是否拼图拼得准而是分析你滑动过程中的轨迹特征加速度曲线是不是符合人类操作、有没有停顿、点击位置是否过于精确。脚本用直线或匀速滑过去几百毫秒内就会被识别为机器操作。import random import time def human_slide_trajectory(distance: int) - list: 生成一段带加速、减速和轻微抖动的人为滑动轨迹 trajectory [] current 0 speed 0 while current distance: # 前半段加速后半段减速最后加一点反向修正 if current distance * 0.7: speed random.uniform(1, 3) else: speed - random.uniform(1, 3) speed max(speed, 0.5) current speed trajectory.append({ x: int(current), y: random.uniform(-1, 1) }) time.sleep(random.uniform(0.005, 0.015)) return trajectory这段轨迹看似符合直觉但我要提醒一句光是轨迹像人远远不够。滑块服务端还会看浏览器环境里的JS指纹、鼠标事件监听上下文、甚至这次滑动对应的会话是否异常。能从脚本层面解决轨迹模拟已经是相对初级的对抗。真正完整的方案需要无头浏览器叠加环境伪装复杂度一下子高很多而且每次平台更新风控算法这一层就得跟着改。4.3 一条务实的降级路径半自动人工介入正因为滑块和签名的组合拳很难完全自动化我见过能稳定用的方案几乎都是半自动的。脚本负责登录、查场次、构造请求、提交订单遇到滑块验证码弹出时程序立刻暂停向用户推送提醒由人工在屏幕上滑一下。这个方案的成功率比纯自动高得多也省掉了无头浏览器的环境维护成本。代价是需要人盯着屏幕但它才是多数人够得着的落地路径。具体实现不复杂在发下单请求之前先发一个预检请求看返回里有没有滑块标记。有就直接抛出一个可识别的异常通知程序进入等待人工处理的状态人工处理完成后把会话里最新的cookie或token填回脚本。如果一套流程能连续跑通三场再考虑要不要把滑块部分也自动化。所以如果你评估自己的时间和精力纯自动脚本要达到“可长期使用”的稳定程度投入产出比很低半自动方案几小时就能搭起来热门场次也能抢到。脚本真的过了三个晚场、没有被风控标记再回头优化也不迟。5. 抢票脚本踩坑实录四个最容易让人放弃的问题这一章写给准备投入时间的人。我不罗列空泛的风险清单直接按“现象→原因→解决”写四个实际调试中重复出现的问题。你自己跑的时候遇到类似提示可以对号入座。5.1 现象登录成功但下单接口一直返回“操作频繁”你以为登录成功就安全了其实登录本身就是一次高危行为。用脚本从陌生环境登录账号尤其是账号绑定的手机号和常用设备不一致时服务端会把这个会话标记为“低信任”。之后访问任何关键接口都会被要求额外验证。原因有两个。一是登录请求的文件指纹不一致网页登录的指纹是浏览器真实生成的脚本里却带了缺失UA和Canvas指纹的环境二是登录后立刻去查库存时间间隔远小于真人操作触发了频率熔断。解决方法是登录后先模拟浏览行为停2到3秒再查第一个接口查库存的频率限制在每10秒一次不要用1秒循环。关键接口务必带全页面真实抓到的请求头从抓包工具里直接复制那一份不要自己拼。5.2 现象网页端能看到库存脚本请求却提示“场次不存在”这个最容易让人懵。网页能看到票说明库存没有清零脚本提示场次不存在说明接口参数有问题。多半是场次ID跟前端展示的不一致或者脚本里的city参数和票档ID对不上。原因通常是抓包抓的是列表页接口而下单接口需要的是详情页的场次ID两者在页面里同名但数值不同。解决在抓包记录里找到“创建订单”前最后一次查询库存的请求以那个请求里的参数为准并且让脚本先调一次详情页接口实时拿场次ID不要硬编码到配置里。5.3 现象滑块验证码频繁弹出且通过后仍报异常滑块弹得频繁说明设备指纹已经被标记了通过后仍报异常说明服务端记录的并不是滑块是否通过而是这次会话中指纹的变化情况。原因常见于脚本运行在普通Python进程里没有完整浏览器环境JS能读取的Canvas、WebGL、字体信息全部缺失这些缺失却和发起登录时的指纹对不上。解决把滑块环节切换到半自动人工介入如果坚持全自动就要上无头浏览器并持久化浏览器Profile让指纹保持稳定。指纹稳定比轨迹模拟重要得多这是很多人没意识到的。5.4 现象下单成功但支付超时下单成功不等于抢到票订单通常只有几分钟支付时间。支付超时的原因一般是脚本构造的下单请求没有带上有效的跳转凭证或者支付入口依赖前端完成。原因创建订单接口返回的跳转链接只在当前会话有效脚本并发重试时创建过多个订单导致前一个订单占用了支付状态。解决让脚本在下单成功后就停止后续请求把支付跳转提示推送给用户手动完成。这也是我坚持做半自动方案的原因之一支付环节交给真人比让脚本去处理跳转和回调稳妥得多。另外抢票成功后的通知要带订单号和支付链接别只发一句“抢到了”等用户打开页面再去找订单支付时间早就过了。这些问题的背后有一个共同原则平台风控关注的是“行为的连贯性”。脚本想要高成功率就得尽量把每一次请求的行为特征维持在同一个指纹和同一个账号画像里。任何突然的变化都会成为被拦截的理由。6. 用日志回放验证脚本本地与线上成功率到底差在哪最后讲验证因为我见过太多人把“跑通一次”当成“可以用了”。验证脚本有没有价值要看三个数据请求发出到订单创建的耗时、触发风控的次数、连续三个场次的稳定表现。我的做法是给脚本加结构化日志把每次下单请求的时间点、接口响应码、耗时、是否出现滑块按JSON格式落盘。每次抢票结束后用一段小脚本做回放分析看请求从发出到拿到订单成功码花了多少毫秒。如果一次成功的耗时在800毫秒以上说明瓶颈在网络或接口本身而不是脚本逻辑如果经常在300毫秒内被拒绝说明频率风控已经盯上了当前指纹。更直观的验证是双开对照同一场次用一个人工浏览器窗口一个脚本终端同时抢。连续测三场如果脚本的提交时间稳定比人工快300毫秒以上才说明这套自动化确实有价值如果两个方式都在同一个时间点失败那就是风控策略的问题不是脚本的问题。单次成功不值得投入三次稳定才值得把时间花在研究签名和滑块上。这个习惯我保持了好几年它帮我戒掉了“跑通即成功”的错觉。希望帮到你。本文还有配套的精品资源点击获取