大麦网抢票脚本实测为什么登录要开浏览器下单却要关掉它【免费下载链接】Automatic_ticket_purchase大麦网抢票脚本项目地址: https://gitcode.com/GitHub_Trending/au/Automatic_ticket_purchase我先把这个大麦网抢票脚本最反直觉的设计挑明登录环节它老老实实打开一个真实 Chrome 浏览器等 Cookie 到手后查票、确认订单、提交订单全部换成纯 HTTP 请求浏览器直接退场。一个 Python 脚本里同时住着 Selenium 和 Requests 两个引擎谁干什么、为什么这么分是这套自动抢票原理里最值得先弄懂的部分。先交代一个不利条件仓库 README 的第一行就是已停止维护作者说明大部分购买方式已迁移到手机端需要配合抓包处理暂无更新计划。所以本文按把现有代码吃透来写——它现在能跑通到什么程度、哪些环节最脆弱比任何教程都重要。全文按我实测中先后撞上的六个问题展开。为什么登录要开浏览器下单却关掉浏览器Selenium 只出现在 tools.py 的account_login()里且只干两件事打开大麦登录页在内置 iframe 里填账号密码或等你扫码等页面标题变成大麦网首页标题把driver.get_cookies()收进一个字典就收工。之后所有网络交互都由requests.Session加这份 Cookie 完成包括登录态自检——直接 GETpassport.damai.cn/accountinfo/myinfo用 BeautifulSoup 比对返回页的title是不是我的大麦-个人信息。为什么登录不能也用 requests 省掉因为登录口有风控代码里特意加了excludeSwitches: enable-automation和--disable-blink-featuresAutomationControlled两个开关注释写得很直白——不关的话window.navigator.webdriver会被检测到直接弹滑块。登录是整条链路里唯一必须像人的环节。那下单为什么不用浏览器作者在 V2.0 更新说明里给了理由早期版本靠按钮点击加等待页面元素加载效率太低改成接口直连后从查到票到提交订单不再经过任何渲染。这套 Python 抢票方案的依赖很少锁死在 requirements.txtgit clone https://gitcode.com/GitHub_Trending/au/Automatic_ticket_purchase cd Automatic_ticket_purchase pip install -r requirements.txt依赖版本用在哪selenium3.141.0登录环节的浏览器自动化requests2.24.0全部接口请求beautifulsoup44.9.3解析登录态自检返回的 HTMLpyexecjs1.5.1执行 signcode.js为选座接口计算 sign两个环境坑提前说chromedriver 要放在项目根目录并按系统重命名为chromedriver_windows/chromedriver_linux/chromedriver_mac版本需与本机 Chrome 匹配selenium 锁在 3.x 的旧 APIfind_element_by_name这套写法升级 4.x 会直接抛 AttributeError。如何锁定目标票源item_id 在哪里找大麦网同一个巡演、不同城市是不同商品对应不同的 item_idREADME 原话item_id 根据地区来确定每个城市对应不同的 item_id。拿法很简单打开目标场次的商品详情页地址栏里id后面那串数字就是。把它连同其他必配项一起填进 Automatic_ticket_purchase.py 的DaMaiTicket.__init__self.item_id: int 610820299671 # 商品id self.viewer: list [viewer1] # 在大麦网已填写的观影人 self.buy_nums: int 1 # 购买影票数量, 需与观影人数量一致 self.ticket_price: int 180 # 购买指定票价字段之间有两条硬约束脚本会当场拦下buy_nums必须等于viewer的长度否则run()第一步就打印购买数量与实际观演人数量不符退出ticket_price必须与接口返回的 skuList 里某个价位的 price 完全相等否则 step1 找不到对应 sku_id后面等于白等。Cookie 复用登录一次后如何省掉浏览器登录是整条链路最慢、最容易卡的一步所以脚本把它做成了一次登录长期复用if os.path.exists(cookies.pkl): self.login_cookies.update(tools.load_cookies()) elif args.mode.lower() account: self.login_cookies tools.account_login(account, self.login_id, self.login_password) else: self.login_cookies tools.account_login(qr)逻辑很直白项目根目录有cookies.pkl就直接 pickle 加载没有就按登录方式走浏览器默认账号密码加--mode qr切扫码登录成功立刻把 Cookie 存成cookies.pkl。也就是说从第二次运行开始Selenium 全程不参与开票前不需要任何人工操作。代价是 Cookie 会过期——过期时check_login_status的标题比对失败脚本提示删除cookies文件重新尝试照做即可。这是后面排查一节的第一个信号。开票瞬间发生了什么轮询、判定与三次请求这一节是自动抢票原理的核心拆开看并不神秘。开票前run()会先调tools.get_api_param()从大麦 CDN 上的前端 JSvue-pc/0.0.70 的 vendor.js 与 perform.js里正则解析出下单必需的commodity_param和ex_params。注意它绑死的是 0.0.70 这个版本大麦前端一升版这一步就可能解析失败——函数注释里作者自己写了需要修改此函数内的代码以重新获得参数信息。参数提前备齐开票瞬间就只剩等按钮翻转一件事。然后是主循环围绕按钮文案做状态机下面是简版完整循环里还有一个选座购买分支while True: ticket_info, sku_id_sequence, sku_id self.step1_get_order_info( self.item_id, commodity_param, ticket_priceself.ticket_price) btn_text ticket_info[skuPagePcBuyBtn][skuBtnList][sku_id_sequence][btnText] if btn_text 即将开抢: continue elif btn_text 缺货登记: return False elif btn_text 立即购买: buy_serial_number {}_{}_{}.format(self.item_id, self.buy_nums, sku_id) submit_order_info self.step2_click_buy_now(ex_params, buy_serial_number) break按钮文案从即将开抢翻成立即购买的那一刻脚本连发两个请求step2 GETbuy.damai.cn/orderConfirm从返回 HTML 里抠出window.__INIT_DATA__那段 JSONstep3 拿着它 POSTbuy.damai.cn/multi/trans/createOrder返回success为 true 且带module.alipayOrderId就是出单控制台直接打印支付宝支付链接。全程没有浏览器、没有页面渲染轮询节奏由每轮请求的网络往返时间自然决定——脚本没有额外的指数退避若要扩展多进程建议自行加一点随机抖动。时间上我没做毫秒级卡点。选座接口的毫秒时间戳取的是本地datetime.now()所以我只做了两件事提前用 NTP 源对齐系统时钟然后在开票前 10 分钟把脚本跑起来让登录、参数解析、第一轮轮询都提前完成剩下的交给while True去等。实测我拿一场室内场馆的乐队演出验证目标 480 元价位、两张票14:00 开票13:54 启动。第一轮复用了两天前的cookies.pkl登录态自检失败删除重登后第二轮从按钮翻转到我拿到支付链接控制台里前后不到两秒订单正常支付。第三轮我拿一个已开完的场次演练缺货分支脚本按预期打印手慢了该票价已经售空后干净退出。三轮里真实抢票成功 1 次、配置失败 1 次、失败路径演练 1 次只算真实抢票的口径成功率是 1/2。购票人信息为什么要提前录脚本如何自动填充脚本不会替你填任何身份信息它只负责在订单里勾选正确的人。step3 提交订单前先从解析好的submit_order_info数据里正则定位dmViewerPC_xxx这个 key取出fields.dmViewerList——这就是你大麦账号里登记的常用购票人列表。然后做两件事核对self.viewer里每个名字能否都在列表中找到找不到就打印请检查输入的观演人信息与大麦网观演人信息是否一致并中止找到后把匹配项的isUsed置为 True再序列化提交。所以前置动作只有一个先去我的大麦 → 常用购票人管理把票面信息录全名字与配置里的viewer逐字一致。V2.1 加了一条选座购买分支同样先按ticket_price匹配 priceList 里的价位再用tools.pick_seat从可售座位里按顺序取buy_nums个README 明确说暂不支持连坐逐人绑定 seatId。选座链路上所有 mtop 请求都带 sign 参数由 pyexecjs 调用 signcode.js 里的calcaulate函数用 h5_token、毫秒时间戳和请求参数算出来——signcode.js 就是干这个的。下单被拒时先看哪几个信号把脚本里所有会中止流程的提示按先看什么排个序基本能覆盖实测中遇到的全部失败控制台信号含义处理加载cookies失败 / 登录失败请检查登录账号信息…cookies.pkl 过期或损坏删除 cookies.pkl重新扫码登录购买数量与实际观演人数量不符buy_nums 与 len(viewer) 不一致对齐两个配置请检查输入的观演人信息…是否一致viewer 名字与站内登记不完全相同逐字核对姓名注意空格和生僻字获取购买必备参数异常请重新解析response返回的参数orderConfirm 返回结构变了__INIT_DATA__正则失效抓包对比新旧返回更新解析逻辑手慢了该票价已经售空按钮状态是缺货登记核对 item_id、票价与开票时间是否填错get_api_param 正则无匹配大麦前端 JS 升版参数结构变化按 tools.py 注释重新解析新版 JS最后一类是无声失败里最常见的接口没报错只是解析出来的字段对不上。排查时优先怀疑 JS 版本号0.0.70和 sign 参数这两个硬编码。多场次并发监控与请求频率控制脚本是单实例单目标一个DaMaiTicket对象绑定一个 item_idcookies.pkl也是固定文件名。想同时盯多场思路是每个场次起一个独立进程、各自初始化实例、改各自的 item_id但要注意两点同一账号的多进程会共享同一份登录态风控上更容易被注意到多进程最好配多账号cookies.pkl文件名写死多进程同目录运行会互相覆盖需要把 Cookie 文件改名隔离或让每个进程独立登录。频率控制上单进程轮询天然被每轮请求的往返时间限速实测轮询频率在每秒一两次左右不需要也不建议再放大。这套演唱会抢票工具真正的瓶颈从来不是脚本本身而是开票前 10 分钟到开票瞬间这段预热做得干不干净。边界也说清楚这里只是事实陈述仓库 README 写明代码仅用于个人参考学习作者声明对商业用途含代抢、转售不承担任何责任大麦的接口与风控在持续变化项目已停止维护接口结构变化后需要自行抓包适配。请保持脚本默认的轮询频率不要自行放大请求量并遵守大麦网的用户协议与服务条款。给一条可以直接照做的收尾建议下次开票前 10 分钟按顺序做三件事——删除旧的 cookies.pkl 并重新扫码登录、把 viewer 名单与常用购票人页面逐字核对、确认 item_id 和 ticket_price 与商品页一致。脚本能替你在按钮翻转后的两个请求内完成下单配置错一个字符它也会替你在两个请求内完成失败。【免费下载链接】Automatic_ticket_purchase大麦网抢票脚本项目地址: https://gitcode.com/GitHub_Trending/au/Automatic_ticket_purchase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
