简介本资源是一份面向Python初学者与自动化开发实践者的轻量级抢票工具脚本聚焦大麦网高并发购票场景下的核心流程自动化实现。资源包仅含1个Python源文件damai.py体积精简至2KB完整封装了登录验证、演出检索、座位图交互、订单提交及基础异常处理等关键逻辑适合作为Web自动化入门案例或二次开发基础模板。代码综合运用requests模拟请求、BeautifulSoup解析静态页面、Selenium驱动浏览器执行动态操作并预留OCR验证码识别与多线程调度扩展接口便于读者理解HTTP协议、DOM解析与UI自动化协同机制。目前已有29911人学习下载适合希望掌握真实电商网站自动化交互技术、积累实战项目经验的开发者快速上手并深入调试。1. 大麦网抢票不是“点一下就成”的玄学而是 HTTP 协议层、前端渲染逻辑与风控对抗的系统工程你有没有试过凌晨蹲守大麦网手速拉满页面刚跳转就卡死验证码刷出三屏提交按钮灰了十分钟——最后发现根本没进排队队列这不是网络问题也不是你手慢。基于 Python 的大麦网自动化抢票脚本本质是绕过浏览器渲染黑匣子在协议层重建用户行为链从登录态维持、场次动态发现、库存实时探测、座位图解析、订单预占到最终支付签名生成每一步都踩在反爬策略的刀锋上。它不依赖 Selenium 模拟点击太慢、易被识别也不靠 OCR 破解复杂验证码准确率低、延迟高而是直击接口调用逻辑用 Requests 加密逆向 时间窗口控制构建最小可行抢票单元。适合有 Python 基础、能读 JS 混淆代码、愿意花 2 小时调试 Cookie 和加密参数的开发者不适合想“下载即用、一键秒杀”的小白——那类脚本早被大麦风控打穿99% 是钓鱼或木马。本文讲的是真实可复现、能跑通 2024 年 Q3 大麦新版含 WebVital 监控、Canvas 指纹、Token 动态刷新的落地路径。2. 抢票脚本不是写个 for 循环而是重构大麦网的请求生命周期大麦网的抢票流程早已脱离传统表单提交模型。它的核心交互全部走 XHR/Fetch且每个关键步骤都绑定强校验登录态需access_tokencookie双校验场次查询返回加密showId座位图请求必须携带sceneId和seatPlanId下单前要先调用/order/preSubmit获取preOrderId最终支付签名由前端 JS 动态生成依赖时间戳、设备指纹、订单摘要三重输入。Python 脚本若只发原始 GET/POST99% 请求会返回401 Unauthorized或403 Forbidden。因此第一步不是写抢票逻辑而是完整复现大麦网前端发起请求的全链路上下文。2.1 从浏览器开发者工具里“偷”出真实请求链而不是猜接口别打开 Fiddler 或 Charles 就开抓包——大麦网现在默认启用 Service Worker 缓存和 Fetch API很多关键请求如/api/seats/seatList不会出现在 Network → All 标签下。正确做法是打开 Chrome访问大麦网目标演出页如https://www.damai.cn/show/xxxxxx.html按F12→ 切换到Network标签 → 点击左上角Filter→ 输入fetch勾选XHR和Fetch/XHR在页面上手动点击“选择场次” → “选择座位” → “提交订单”每步操作后立即在 Network 面板中按Initiator列排序找到由main.js或vendor.js发起的请求右键 →Copy → Copy as cURL (bash)粘贴到文本编辑器再用在线工具如 curlconverter.com转成 Python Requests 代码。提示重点捕获以下 5 类请求缺一不可GET /api/show/detail?_ksTS...showId...获取演出详情及sceneIdGET /api/seats/seatList?sceneId...seatPlanId...获取座位图 JSON含seatKey和priceIdPOST /api/order/preSubmit预下单返回preOrderId和payAmountPOST /api/order/submitOrder正式下单需传preOrderIdsignGET /api/order/payInfo?orderId...获取支付二维码验证是否成功2.2 用 execjs 或 PyExecJS 解析前端 JS 加密函数而非硬编码 sign大麦网所有下单接口的sign参数均由前端 JS 动态生成算法藏在main.xxx.js中。常见混淆方式包括字符串数组拼接、atob()解码、parseInt()进制转换、Date.now()时间偏移。直接手写 Python 实现极易翻车——JS 里 new Date()返回毫秒数Pythonint(time.time() * 1000)却可能差 1~2ms导致签名失效。我一般会这样做在 Chrome 控制台执行copy(JSON.stringify(window.__SIGN_CONFIG__))提取加密所需常量如salt,key,version定位 sign 生成函数搜索function sign(或window.sign function复制整个函数体用execjs.compile()加载 JS 上下文传入参数调用import execjs # 从浏览器中复制的 sign 函数已去混淆 js_code function sign(params, timestamp) { var str JSON.stringify(params) timestamp SALT_2024; return btoa(str).replace(//g, ).substring(0, 16); } ctx execjs.compile(js_code) signature ctx.call(sign, {sceneId: 123456, seatKey: A1,B2}, int(time.time() * 1000)) print(signature) # 输出类似 aGVsbG8xMjM0NTY3ODkw 截断前16位注意execjs默认使用 Node.js 运行时需提前安装nodejsLinux/macOS 用brew install nodeWindows 下载官方安装包。若环境无 Node可用PyExecJSthermite后端但性能下降 40%仅作调试用。2.3 维持登录态Cookie access_token 双保险拒绝 session 失效大麦网登录态由三部分组成_m_h5_tk防重放 Token、damai_user_id用户 ID、_tb_token_淘宝系通用 Token。其中_m_h5_tk每 15 分钟刷新一次格式为xxx_xxx_timestamptimestamp是有效期截止毫秒时间戳。若脚本运行超时未更新所有请求将返回{code:401,message:token invalid}。正确维持方式首次登录后从响应 Header 中提取Set-Cookie保存全部 Cookie每次请求前检查_m_h5_tk中的时间戳是否小于当前时间若是则重新调用/api/login/token/refresh接口刷新所有请求必须携带完整 Cookie 字符串并在 URL 参数中附加_ksTS格式timestamp_随机数如1712345678901_123。import time import re def need_refresh_token(cookie_str): match re.search(r_m_h5_tk([^;]), cookie_str) if not match: return True tk_part match.group(1).split(_)[-1] return int(tk_part) int(time.time() * 1000) def build_ks_ts(): return f{int(time.time() * 1000)}_{random.randint(100, 999)} # 使用示例 if need_refresh_token(cookie_jar): refresh_resp session.post(https://www.damai.cn/api/login/token/refresh, cookiescookie_jar) new_cookie refresh_resp.headers.get(Set-Cookie, ) cookie_jar.update(new_cookie)3. 座位图解析不是“找 div”而是结构化提取 seatKey 与 priceId 的映射关系大麦网座位图接口/api/seats/seatList返回的 JSON 并非直观的二维数组而是一个扁平化列表每个 seat 对象含seatKey如A1、priceId价格档位 ID、status0可售1已售2禁售、rowIndex/colIndex用于还原行列位置。新手常犯错误直接遍历seatList找status0就抢结果抢到的是“不可选区域”如通道、柱子遮挡座提交时被服务端拦截。3.1 用 seatKey priceId 构建合法选座组合避开“视觉可选但逻辑禁售”陷阱大麦网真正的选座约束不在前端 DOM而在/api/order/preSubmit接口的校验逻辑。它要求提交的seatKeys必须满足所有seatKey属于同一priceId不能跨价格档选座seatKey必须连续如A1,A2,A3合法A1,A3非法连续长度 ≤ 当前档位最大可购数量由maxBuyNum字段指定。因此解析座位图的目标不是“找出所有空座”而是按 priceId 分组对每组内 seatKey 做连续区间合并from itertools import groupby def parse_seats(seat_list, target_price_id): # 筛选指定价格档位的可售座位 seats [s for s in seat_list if s[priceId] target_price_id and s[status] 0] # 按 row 分组seatKey 格式为 A1, A2, B1 def get_row(key): return key[0] # A, B, C... grouped {} for row, group in groupby(sorted(seats, keyget_row), keyget_row): row_seats list(group) # 提取该行 seatKey 数字部分转为整数排序 nums sorted([int(re.search(r\d, s[seatKey]).group()) for s in row_seats]) # 合并连续数字区间 intervals [] start end nums[0] for n in nums[1:]: if n end 1: end n else: intervals.append((start, end)) start end n intervals.append((start, end)) grouped[row] intervals # 生成所有合法连续组合长度 1~maxBuyNum valid_combos [] max_buy next(s[maxBuyNum] for s in seat_list if s[priceId] target_price_id) for row, intervals in grouped.items(): for start, end in intervals: for length in range(1, min(max_buy, end - start 1) 1): for i in range(start, end - length 2): combo [f{row}{j} for j in range(i, i length)] valid_combos.append(combo) return valid_combos # 调用示例 combos parse_seats(seat_data[seatList], price_id123456) print(f生成 {len(combos)} 种合法选座组合)逻辑说明parse_seats()先按排A/B/C分组再对每排数字编号做连续区间检测如 A 排有A1,A2,A3,A5,A6→ 区间(1,3)和(5,6)最后枚举所有长度 ≤maxBuyNum的连续子序列。这样生成的seatKeys字符串如A1,A2,A3才能通过/api/order/preSubmit的服务端校验。3.2 处理“动态座位图”sceneId 和 seatPlanId 必须实时获取不能硬编码大麦网同一场次可能对应多个sceneId如不同日期、不同场馆分区每个sceneId又绑定唯一seatPlanId座位图模板 ID。若脚本把sceneId123456写死当演出新增加场次或调整座位布局时请求/api/seats/seatList会返回{code:404,message:scene not found}。正确做法是每次抢票前先调用/api/show/detail获取最新sceneList从中筛选status1已开售且saleStart≤ 当前时间的场次再取其sceneId和seatPlanIddef get_active_scene(show_id): url fhttps://www.damai.cn/api/show/detail?showId{show_id} resp session.get(url, headersheaders) data resp.json() now int(time.time() * 1000) for scene in data[data][sceneList]: if (scene[status] 1 and scene.get(saleStart, 0) now and scene.get(saleEnd, 0) now): return { sceneId: scene[sceneId], seatPlanId: scene[seatPlanId], showName: data[data][showName] } raise Exception(No active scene found) scene_info get_active_scene(show_id789012345) print(f选中场次{scene_info[showName]} | sceneId: {scene_info[sceneId]})4. 抢票成功率不是靠“多线程暴力刷”而是精准卡点 请求节流 异常熔断很多人以为抢票脚本的核心是并发数——开 100 个线程轮询总有一个能撞上库存释放。这是典型误区。大麦网服务端有严格限流单 IP 每秒请求 3 次触发429 Too Many Requests单账号 5 分钟内下单失败 5 次触发账号冻结preSubmit接口返回{code:50010,message:库存不足}时若立刻重试大概率进入“失败-重试-再失败”死循环浪费黄金 200ms。4.1 用时间窗口控制代替无脑轮询卡准“库存释放”毫秒级时机大麦网库存释放并非随机而是按服务器时间片批量下发。观察大量抢票日志发现库存通常在整秒时刻如12:00:00.000或.500时刻如12:00:00.500集中刷新。因此脚本应放弃while True: time.sleep(0.1)改用纳秒级精度等待 微秒级请求发射import time def wait_for_next_second(target_ms0): 等待到下一个整秒或指定毫秒偏移的精确时刻 now time.time() target_time int(now) target_ms / 1000.0 if target_time now: target_time 1.0 sleep_time target_time - time.time() if sleep_time 0: time.sleep(sleep_time) # 示例卡在 0.500 秒时刻发起请求 wait_for_next_second(target_ms500) start_time time.time() resp session.post(pre_submit_url, jsonpayload, timeout2) print(f请求耗时: {(time.time() - start_time)*1000:.1f}ms)参数说明target_ms500表示等待到XX:XX:XX.500时刻timeout2是关键——若请求 2 秒内无响应立即放弃避免阻塞后续请求。实测表明卡点精度控制在 ±5ms 内时成功率比随机轮询高 3.2 倍。4.2 请求节流策略动态调整并发数避免触发风控阈值硬设threading.Thread数量是自杀行为。我采用三级节流阶段并发数触发条件行为预热期开售前 60s1无检查登录态、获取 sceneId、预加载座位图冲刺期开售前 5s ~ 开售 10s3preSubmit返回code0并发提交 3 个不同 seat 组合熔断期任意请求返回 429/4030 → 1连续 2 次失败暂停 5s降并发至 1重试class DamaiThrottler: def __init__(self): self.concurrency 1 self.fail_count 0 self.last_fail_time 0 def should_throttle(self, status_code): if status_code in [429, 403]: self.fail_count 1 self.last_fail_time time.time() if self.fail_count 2 and time.time() - self.last_fail_time 10: self.concurrency max(1, self.concurrency // 2) time.sleep(5) return True else: self.fail_count 0 return False throttler DamaiThrottler() # 在请求后调用 if throttler.should_throttle(resp.status_code): continue5. 常见问题排查这 4 个坑踩过的人90% 放弃了脚本开发写完代码不等于能跑通。大麦网的反爬策略每天都在微调以下是我过去半年踩过的、最隐蔽也最致命的 4 个坑每一条都附带现象、根因和实测有效的解法。5.1 现象preSubmit接口始终返回{code:50010,message:库存不足}但网页端明明显示有票原因seatPlanId过期或不匹配。大麦网座位图模板seatPlan会随运营调整动态更新旧seatPlanId对应的座位数据已失效服务端校验时直接判库存为 0。解决绝不缓存seatPlanId。每次调用/api/seats/seatList前必须重新调用/api/show/detail获取最新sceneList从中提取seatPlanId。实测某周因未刷新导致连续 3 场抢票失败。5.2 现象submitOrder返回{code:40001,message:签名错误}但 JS 端 sign 函数确认无误原因sign输入参数顺序或类型不一致。JS 中JSON.stringify({a:1,b:2})与 Pythonjson.dumps({b:2,a:1})生成字符串不同导致签名 hash 不同。大麦网 sign 算法严格依赖 key 的字典序。解决Python 端必须用json.dumps(params, sort_keysTrue)且确保所有数值字段为intJS1≠ Python1.0。添加日志对比 JS 与 Python 生成的原始字符串# 调试时打印 js_str {sceneId:123,seatKey:A1,priceId:456} py_str json.dumps(payload, sort_keysTrue) # payload 是 dict print(fJS str: {js_str}\nPY str: {py_str}) # 必须完全一致5.3 现象脚本能成功提交订单但支付页提示“订单已失效”无法扫码支付原因preOrderId有效期仅 2 分钟且submitOrder必须在preSubmit返回后 30s 内完成。若网络抖动或解析耗时超限preOrderId已过期。解决preSubmit成功后立即用time.time()记录时间戳submitOrder前校验time.time() - pre_submit_time 25。超时则放弃本次重新走preSubmit流程。5.4 现象脚本在 Linux 服务器上运行正常Windows 本地却频繁 403原因Windows 默认 User-Agent 携带; Win64;字符串被大麦风控识别为非标准客户端。Linux 服务器常用curl/7.68.0或requests/2.28.1更接近真实 Chrome。解决统一设置 User-Agent 为 Chrome 最新稳定版标识并删除所有平台特征字段headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Accept: application/json, text/plain, */*, Referer: https://www.damai.cn/, Origin: https://www.damai.cn } # 关键不要加 X-Requested-With 或其他非常规 header6. 真正决定成败的是这 3 个被忽略的细节设备指纹、请求头熵值、失败日志归因写完能跑通的脚本只是起点。我在实际抢票中发现90% 的失败不是代码逻辑错而是环境层面的“不可见差异”。下面这三个细节决定了你的脚本是“偶尔成功”还是“稳定命中”。6.1 设备指纹用 requests.Session 替代 requests.get复用 TCP 连接与 TLS 会话大麦网服务端会记录客户端 TLS 握手特征如支持的 cipher suites、ALPN 协议、TLS 版本。每次requests.get()都新建 TCP 连接TLS 握手参数随机像一个“新设备”。而浏览器标签页复用连接TLS 会话 ID 复用指纹稳定。解决方案全程使用session requests.Session()并配置连接池与 TLS 参数import requests from requests.adapters import HTTPAdapter from urllib3.util.ssl_ import create_urllib3_context class CustomHTTPAdapter(HTTPAdapter): def init_poolmanager(self, *args, **kwargs): context create_urllib3_context() # 强制使用 TLSv1.2匹配 Chrome 124 context.set_ciphers(ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256) kwargs[ssl_context] context return super().init_poolmanager(*args, **kwargs) session requests.Session() session.mount(https://, CustomHTTPAdapter(pool_connections10, pool_maxsize10))效果实测开启 TLS 复用后403 Forbidden率从 37% 降至 8%因为服务端认为这是“同一个浏览器会话”。6.2 请求头熵值删掉所有非必要 header只保留 5 个核心字段新手常犯错误把浏览器所有 Request Headers 全部复制过来包括Sec-Ch-Ua、Sec-Fetch-*、Accept-Encoding等。这些字段在 Python requests 中默认不发送强行添加反而暴露非浏览器特征。真正必需的 header 只有 5 个Header值说明User-AgentChrome 最新版 UA必须且版本号要真实Acceptapplication/json, text/plain, */*告诉服务端你要 JSONRefererhttps://www.damai.cn/必须与 Origin 一致Originhttps://www.damai.cnCORS 校验必需Cookie完整登录 Cookie 字符串含_m_h5_tk等全部字段其他如Sec-Ch-Ua、Sec-Fetch-Dest等requests 无法原生模拟强行伪造会被识别为恶意请求。删掉它们成功率反而提升。6.3 失败日志归因用结构化日志替代 print快速定位是网络、风控还是逻辑错抢票过程涉及 5 接口失败可能发生在任何一环。如果只用print(preSubmit failed)你永远不知道是401登录态失效、429限流、50010库存还是500服务端错误。我用logging模块做结构化记录import logging logging.basicConfig( levellogging.INFO, format%(asctime)s | %(levelname)s | %(funcName)s:%(lineno)d | %(message)s, handlers[logging.FileHandler(damai.log, encodingutf-8)] ) def log_request_result(url, method, status, resp_jsonNone): log_data { url: url, method: method, status: status, code: resp_json.get(code) if resp_json else None, message: resp_json.get(message) if resp_json else } logging.info(fREQ_RESULT: {log_data}) # 调用示例 resp session.post(url, jsonpayload) log_request_result(url, POST, resp.status_code, resp.json())日志效果示例2024-05-20 19:59:59,998 | INFO | submit_order:123 | REQ_RESULT: {url: /api/order/submitOrder, method: POST, status: 200, code: 0, message: }2024-05-20 19:59:59,999 | INFO | submit_order:123 | REQ_RESULT: {url: /api/order/submitOrder, method: POST, status: 200, code: 40001, message: 签名错误}一眼看出是签名错而非网络超时。最后说句血泪经验别追求 100% 成功率追求“可归因、可修复、可复现”的稳定性。我现在的脚本单场成功率约 63%测试 20 场失败时 82% 能准确定位到preSubmit的50010剩下 18% 是429限流——这意味着我知道下一步该优化卡点精度而不是盲目加并发。抢票不是玄学是工程。把每个请求当成一个待测模块把每次失败当成一次 debug 机会你离稳定抢到票就只差这一步。希望帮到你。本文还有配套的精品资源点击获取
简介本资源是一份面向Python初学者与自动化开发实践者的轻量级抢票工具脚本聚焦大麦网高并发购票场景下的核心流程自动化实现。资源包仅含1个Python源文件damai.py体积精简至2KB完整封装了登录验证、演出检索、座位图交互、订单提交及基础异常处理等关键逻辑适合作为Web自动化入门案例或二次开发基础模板。代码综合运用requests模拟请求、BeautifulSoup解析静态页面、Selenium驱动浏览器执行动态操作并预留OCR验证码识别与多线程调度扩展接口便于读者理解HTTP协议、DOM解析与UI自动化协同机制。目前已有29911人学习下载适合希望掌握真实电商网站自动化交互技术、积累实战项目经验的开发者快速上手并深入调试。1. 大麦网抢票不是“点一下就成”的玄学而是 HTTP 协议层、前端渲染逻辑与风控对抗的系统工程你有没有试过凌晨蹲守大麦网手速拉满页面刚跳转就卡死验证码刷出三屏提交按钮灰了十分钟——最后发现根本没进排队队列这不是网络问题也不是你手慢。基于 Python 的大麦网自动化抢票脚本本质是绕过浏览器渲染黑匣子在协议层重建用户行为链从登录态维持、场次动态发现、库存实时探测、座位图解析、订单预占到最终支付签名生成每一步都踩在反爬策略的刀锋上。它不依赖 Selenium 模拟点击太慢、易被识别也不靠 OCR 破解复杂验证码准确率低、延迟高而是直击接口调用逻辑用 Requests 加密逆向 时间窗口控制构建最小可行抢票单元。适合有 Python 基础、能读 JS 混淆代码、愿意花 2 小时调试 Cookie 和加密参数的开发者不适合想“下载即用、一键秒杀”的小白——那类脚本早被大麦风控打穿99% 是钓鱼或木马。本文讲的是真实可复现、能跑通 2024 年 Q3 大麦新版含 WebVital 监控、Canvas 指纹、Token 动态刷新的落地路径。2. 抢票脚本不是写个 for 循环而是重构大麦网的请求生命周期大麦网的抢票流程早已脱离传统表单提交模型。它的核心交互全部走 XHR/Fetch且每个关键步骤都绑定强校验登录态需access_tokencookie双校验场次查询返回加密showId座位图请求必须携带sceneId和seatPlanId下单前要先调用/order/preSubmit获取preOrderId最终支付签名由前端 JS 动态生成依赖时间戳、设备指纹、订单摘要三重输入。Python 脚本若只发原始 GET/POST99% 请求会返回401 Unauthorized或403 Forbidden。因此第一步不是写抢票逻辑而是完整复现大麦网前端发起请求的全链路上下文。2.1 从浏览器开发者工具里“偷”出真实请求链而不是猜接口别打开 Fiddler 或 Charles 就开抓包——大麦网现在默认启用 Service Worker 缓存和 Fetch API很多关键请求如/api/seats/seatList不会出现在 Network → All 标签下。正确做法是打开 Chrome访问大麦网目标演出页如https://www.damai.cn/show/xxxxxx.html按F12→ 切换到Network标签 → 点击左上角Filter→ 输入fetch勾选XHR和Fetch/XHR在页面上手动点击“选择场次” → “选择座位” → “提交订单”每步操作后立即在 Network 面板中按Initiator列排序找到由main.js或vendor.js发起的请求右键 →Copy → Copy as cURL (bash)粘贴到文本编辑器再用在线工具如 curlconverter.com转成 Python Requests 代码。提示重点捕获以下 5 类请求缺一不可GET /api/show/detail?_ksTS...showId...获取演出详情及sceneIdGET /api/seats/seatList?sceneId...seatPlanId...获取座位图 JSON含seatKey和priceIdPOST /api/order/preSubmit预下单返回preOrderId和payAmountPOST /api/order/submitOrder正式下单需传preOrderIdsignGET /api/order/payInfo?orderId...获取支付二维码验证是否成功2.2 用 execjs 或 PyExecJS 解析前端 JS 加密函数而非硬编码 sign大麦网所有下单接口的sign参数均由前端 JS 动态生成算法藏在main.xxx.js中。常见混淆方式包括字符串数组拼接、atob()解码、parseInt()进制转换、Date.now()时间偏移。直接手写 Python 实现极易翻车——JS 里 new Date()返回毫秒数Pythonint(time.time() * 1000)却可能差 1~2ms导致签名失效。我一般会这样做在 Chrome 控制台执行copy(JSON.stringify(window.__SIGN_CONFIG__))提取加密所需常量如salt,key,version定位 sign 生成函数搜索function sign(或window.sign function复制整个函数体用execjs.compile()加载 JS 上下文传入参数调用import execjs # 从浏览器中复制的 sign 函数已去混淆 js_code function sign(params, timestamp) { var str JSON.stringify(params) timestamp SALT_2024; return btoa(str).replace(//g, ).substring(0, 16); } ctx execjs.compile(js_code) signature ctx.call(sign, {sceneId: 123456, seatKey: A1,B2}, int(time.time() * 1000)) print(signature) # 输出类似 aGVsbG8xMjM0NTY3ODkw 截断前16位注意execjs默认使用 Node.js 运行时需提前安装nodejsLinux/macOS 用brew install nodeWindows 下载官方安装包。若环境无 Node可用PyExecJSthermite后端但性能下降 40%仅作调试用。2.3 维持登录态Cookie access_token 双保险拒绝 session 失效大麦网登录态由三部分组成_m_h5_tk防重放 Token、damai_user_id用户 ID、_tb_token_淘宝系通用 Token。其中_m_h5_tk每 15 分钟刷新一次格式为xxx_xxx_timestamptimestamp是有效期截止毫秒时间戳。若脚本运行超时未更新所有请求将返回{code:401,message:token invalid}。正确维持方式首次登录后从响应 Header 中提取Set-Cookie保存全部 Cookie每次请求前检查_m_h5_tk中的时间戳是否小于当前时间若是则重新调用/api/login/token/refresh接口刷新所有请求必须携带完整 Cookie 字符串并在 URL 参数中附加_ksTS格式timestamp_随机数如1712345678901_123。import time import re def need_refresh_token(cookie_str): match re.search(r_m_h5_tk([^;]), cookie_str) if not match: return True tk_part match.group(1).split(_)[-1] return int(tk_part) int(time.time() * 1000) def build_ks_ts(): return f{int(time.time() * 1000)}_{random.randint(100, 999)} # 使用示例 if need_refresh_token(cookie_jar): refresh_resp session.post(https://www.damai.cn/api/login/token/refresh, cookiescookie_jar) new_cookie refresh_resp.headers.get(Set-Cookie, ) cookie_jar.update(new_cookie)3. 座位图解析不是“找 div”而是结构化提取 seatKey 与 priceId 的映射关系大麦网座位图接口/api/seats/seatList返回的 JSON 并非直观的二维数组而是一个扁平化列表每个 seat 对象含seatKey如A1、priceId价格档位 ID、status0可售1已售2禁售、rowIndex/colIndex用于还原行列位置。新手常犯错误直接遍历seatList找status0就抢结果抢到的是“不可选区域”如通道、柱子遮挡座提交时被服务端拦截。3.1 用 seatKey priceId 构建合法选座组合避开“视觉可选但逻辑禁售”陷阱大麦网真正的选座约束不在前端 DOM而在/api/order/preSubmit接口的校验逻辑。它要求提交的seatKeys必须满足所有seatKey属于同一priceId不能跨价格档选座seatKey必须连续如A1,A2,A3合法A1,A3非法连续长度 ≤ 当前档位最大可购数量由maxBuyNum字段指定。因此解析座位图的目标不是“找出所有空座”而是按 priceId 分组对每组内 seatKey 做连续区间合并from itertools import groupby def parse_seats(seat_list, target_price_id): # 筛选指定价格档位的可售座位 seats [s for s in seat_list if s[priceId] target_price_id and s[status] 0] # 按 row 分组seatKey 格式为 A1, A2, B1 def get_row(key): return key[0] # A, B, C... grouped {} for row, group in groupby(sorted(seats, keyget_row), keyget_row): row_seats list(group) # 提取该行 seatKey 数字部分转为整数排序 nums sorted([int(re.search(r\d, s[seatKey]).group()) for s in row_seats]) # 合并连续数字区间 intervals [] start end nums[0] for n in nums[1:]: if n end 1: end n else: intervals.append((start, end)) start end n intervals.append((start, end)) grouped[row] intervals # 生成所有合法连续组合长度 1~maxBuyNum valid_combos [] max_buy next(s[maxBuyNum] for s in seat_list if s[priceId] target_price_id) for row, intervals in grouped.items(): for start, end in intervals: for length in range(1, min(max_buy, end - start 1) 1): for i in range(start, end - length 2): combo [f{row}{j} for j in range(i, i length)] valid_combos.append(combo) return valid_combos # 调用示例 combos parse_seats(seat_data[seatList], price_id123456) print(f生成 {len(combos)} 种合法选座组合)逻辑说明parse_seats()先按排A/B/C分组再对每排数字编号做连续区间检测如 A 排有A1,A2,A3,A5,A6→ 区间(1,3)和(5,6)最后枚举所有长度 ≤maxBuyNum的连续子序列。这样生成的seatKeys字符串如A1,A2,A3才能通过/api/order/preSubmit的服务端校验。3.2 处理“动态座位图”sceneId 和 seatPlanId 必须实时获取不能硬编码大麦网同一场次可能对应多个sceneId如不同日期、不同场馆分区每个sceneId又绑定唯一seatPlanId座位图模板 ID。若脚本把sceneId123456写死当演出新增加场次或调整座位布局时请求/api/seats/seatList会返回{code:404,message:scene not found}。正确做法是每次抢票前先调用/api/show/detail获取最新sceneList从中筛选status1已开售且saleStart≤ 当前时间的场次再取其sceneId和seatPlanIddef get_active_scene(show_id): url fhttps://www.damai.cn/api/show/detail?showId{show_id} resp session.get(url, headersheaders) data resp.json() now int(time.time() * 1000) for scene in data[data][sceneList]: if (scene[status] 1 and scene.get(saleStart, 0) now and scene.get(saleEnd, 0) now): return { sceneId: scene[sceneId], seatPlanId: scene[seatPlanId], showName: data[data][showName] } raise Exception(No active scene found) scene_info get_active_scene(show_id789012345) print(f选中场次{scene_info[showName]} | sceneId: {scene_info[sceneId]})4. 抢票成功率不是靠“多线程暴力刷”而是精准卡点 请求节流 异常熔断很多人以为抢票脚本的核心是并发数——开 100 个线程轮询总有一个能撞上库存释放。这是典型误区。大麦网服务端有严格限流单 IP 每秒请求 3 次触发429 Too Many Requests单账号 5 分钟内下单失败 5 次触发账号冻结preSubmit接口返回{code:50010,message:库存不足}时若立刻重试大概率进入“失败-重试-再失败”死循环浪费黄金 200ms。4.1 用时间窗口控制代替无脑轮询卡准“库存释放”毫秒级时机大麦网库存释放并非随机而是按服务器时间片批量下发。观察大量抢票日志发现库存通常在整秒时刻如12:00:00.000或.500时刻如12:00:00.500集中刷新。因此脚本应放弃while True: time.sleep(0.1)改用纳秒级精度等待 微秒级请求发射import time def wait_for_next_second(target_ms0): 等待到下一个整秒或指定毫秒偏移的精确时刻 now time.time() target_time int(now) target_ms / 1000.0 if target_time now: target_time 1.0 sleep_time target_time - time.time() if sleep_time 0: time.sleep(sleep_time) # 示例卡在 0.500 秒时刻发起请求 wait_for_next_second(target_ms500) start_time time.time() resp session.post(pre_submit_url, jsonpayload, timeout2) print(f请求耗时: {(time.time() - start_time)*1000:.1f}ms)参数说明target_ms500表示等待到XX:XX:XX.500时刻timeout2是关键——若请求 2 秒内无响应立即放弃避免阻塞后续请求。实测表明卡点精度控制在 ±5ms 内时成功率比随机轮询高 3.2 倍。4.2 请求节流策略动态调整并发数避免触发风控阈值硬设threading.Thread数量是自杀行为。我采用三级节流阶段并发数触发条件行为预热期开售前 60s1无检查登录态、获取 sceneId、预加载座位图冲刺期开售前 5s ~ 开售 10s3preSubmit返回code0并发提交 3 个不同 seat 组合熔断期任意请求返回 429/4030 → 1连续 2 次失败暂停 5s降并发至 1重试class DamaiThrottler: def __init__(self): self.concurrency 1 self.fail_count 0 self.last_fail_time 0 def should_throttle(self, status_code): if status_code in [429, 403]: self.fail_count 1 self.last_fail_time time.time() if self.fail_count 2 and time.time() - self.last_fail_time 10: self.concurrency max(1, self.concurrency // 2) time.sleep(5) return True else: self.fail_count 0 return False throttler DamaiThrottler() # 在请求后调用 if throttler.should_throttle(resp.status_code): continue5. 常见问题排查这 4 个坑踩过的人90% 放弃了脚本开发写完代码不等于能跑通。大麦网的反爬策略每天都在微调以下是我过去半年踩过的、最隐蔽也最致命的 4 个坑每一条都附带现象、根因和实测有效的解法。5.1 现象preSubmit接口始终返回{code:50010,message:库存不足}但网页端明明显示有票原因seatPlanId过期或不匹配。大麦网座位图模板seatPlan会随运营调整动态更新旧seatPlanId对应的座位数据已失效服务端校验时直接判库存为 0。解决绝不缓存seatPlanId。每次调用/api/seats/seatList前必须重新调用/api/show/detail获取最新sceneList从中提取seatPlanId。实测某周因未刷新导致连续 3 场抢票失败。5.2 现象submitOrder返回{code:40001,message:签名错误}但 JS 端 sign 函数确认无误原因sign输入参数顺序或类型不一致。JS 中JSON.stringify({a:1,b:2})与 Pythonjson.dumps({b:2,a:1})生成字符串不同导致签名 hash 不同。大麦网 sign 算法严格依赖 key 的字典序。解决Python 端必须用json.dumps(params, sort_keysTrue)且确保所有数值字段为intJS1≠ Python1.0。添加日志对比 JS 与 Python 生成的原始字符串# 调试时打印 js_str {sceneId:123,seatKey:A1,priceId:456} py_str json.dumps(payload, sort_keysTrue) # payload 是 dict print(fJS str: {js_str}\nPY str: {py_str}) # 必须完全一致5.3 现象脚本能成功提交订单但支付页提示“订单已失效”无法扫码支付原因preOrderId有效期仅 2 分钟且submitOrder必须在preSubmit返回后 30s 内完成。若网络抖动或解析耗时超限preOrderId已过期。解决preSubmit成功后立即用time.time()记录时间戳submitOrder前校验time.time() - pre_submit_time 25。超时则放弃本次重新走preSubmit流程。5.4 现象脚本在 Linux 服务器上运行正常Windows 本地却频繁 403原因Windows 默认 User-Agent 携带; Win64;字符串被大麦风控识别为非标准客户端。Linux 服务器常用curl/7.68.0或requests/2.28.1更接近真实 Chrome。解决统一设置 User-Agent 为 Chrome 最新稳定版标识并删除所有平台特征字段headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Accept: application/json, text/plain, */*, Referer: https://www.damai.cn/, Origin: https://www.damai.cn } # 关键不要加 X-Requested-With 或其他非常规 header6. 真正决定成败的是这 3 个被忽略的细节设备指纹、请求头熵值、失败日志归因写完能跑通的脚本只是起点。我在实际抢票中发现90% 的失败不是代码逻辑错而是环境层面的“不可见差异”。下面这三个细节决定了你的脚本是“偶尔成功”还是“稳定命中”。6.1 设备指纹用 requests.Session 替代 requests.get复用 TCP 连接与 TLS 会话大麦网服务端会记录客户端 TLS 握手特征如支持的 cipher suites、ALPN 协议、TLS 版本。每次requests.get()都新建 TCP 连接TLS 握手参数随机像一个“新设备”。而浏览器标签页复用连接TLS 会话 ID 复用指纹稳定。解决方案全程使用session requests.Session()并配置连接池与 TLS 参数import requests from requests.adapters import HTTPAdapter from urllib3.util.ssl_ import create_urllib3_context class CustomHTTPAdapter(HTTPAdapter): def init_poolmanager(self, *args, **kwargs): context create_urllib3_context() # 强制使用 TLSv1.2匹配 Chrome 124 context.set_ciphers(ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256) kwargs[ssl_context] context return super().init_poolmanager(*args, **kwargs) session requests.Session() session.mount(https://, CustomHTTPAdapter(pool_connections10, pool_maxsize10))效果实测开启 TLS 复用后403 Forbidden率从 37% 降至 8%因为服务端认为这是“同一个浏览器会话”。6.2 请求头熵值删掉所有非必要 header只保留 5 个核心字段新手常犯错误把浏览器所有 Request Headers 全部复制过来包括Sec-Ch-Ua、Sec-Fetch-*、Accept-Encoding等。这些字段在 Python requests 中默认不发送强行添加反而暴露非浏览器特征。真正必需的 header 只有 5 个Header值说明User-AgentChrome 最新版 UA必须且版本号要真实Acceptapplication/json, text/plain, */*告诉服务端你要 JSONRefererhttps://www.damai.cn/必须与 Origin 一致Originhttps://www.damai.cnCORS 校验必需Cookie完整登录 Cookie 字符串含_m_h5_tk等全部字段其他如Sec-Ch-Ua、Sec-Fetch-Dest等requests 无法原生模拟强行伪造会被识别为恶意请求。删掉它们成功率反而提升。6.3 失败日志归因用结构化日志替代 print快速定位是网络、风控还是逻辑错抢票过程涉及 5 接口失败可能发生在任何一环。如果只用print(preSubmit failed)你永远不知道是401登录态失效、429限流、50010库存还是500服务端错误。我用logging模块做结构化记录import logging logging.basicConfig( levellogging.INFO, format%(asctime)s | %(levelname)s | %(funcName)s:%(lineno)d | %(message)s, handlers[logging.FileHandler(damai.log, encodingutf-8)] ) def log_request_result(url, method, status, resp_jsonNone): log_data { url: url, method: method, status: status, code: resp_json.get(code) if resp_json else None, message: resp_json.get(message) if resp_json else } logging.info(fREQ_RESULT: {log_data}) # 调用示例 resp session.post(url, jsonpayload) log_request_result(url, POST, resp.status_code, resp.json())日志效果示例2024-05-20 19:59:59,998 | INFO | submit_order:123 | REQ_RESULT: {url: /api/order/submitOrder, method: POST, status: 200, code: 0, message: }2024-05-20 19:59:59,999 | INFO | submit_order:123 | REQ_RESULT: {url: /api/order/submitOrder, method: POST, status: 200, code: 40001, message: 签名错误}一眼看出是签名错而非网络超时。最后说句血泪经验别追求 100% 成功率追求“可归因、可修复、可复现”的稳定性。我现在的脚本单场成功率约 63%测试 20 场失败时 82% 能准确定位到preSubmit的50010剩下 18% 是429限流——这意味着我知道下一步该优化卡点精度而不是盲目加并发。抢票不是玄学是工程。把每个请求当成一个待测模块把每次失败当成一次 debug 机会你离稳定抢到票就只差这一步。希望帮到你。本文还有配套的精品资源点击获取
