企业官网建设流程全解析

大麦抢票完整实战手册：10分钟跑通 Selenium 自动抢票，开售瞬间替你点"立即购买"

【免费下载链接】ticket-purchase大麦自动抢票，支持人员、城市、日期场次、价格选择项目地址: https://gitcode.com/GitHub_Trending/ti/ticket-purchase

开售倒计时 3 秒，你的手停在"刷新"上，票没了。而机器不需要这 3 秒——大麦自动抢票工具 ticket-purchase把"刷新页面、选城市、选场次、选票档、提交订单"这 5 步压缩成一次 80 毫秒级的轮询，你只需要提前把配置写好，剩下的交给Selenium和Appium双引擎替你执行。

30 秒看懂它凭什么快

这一节给你 4 个数字，帮你判断它值不值得装。

• 双引擎架构：Web 端用 Selenium 控制 Chrome，移动端用 Appium 驱动大麦 App，两端各有一条独立票源通道，互不干扰
• Cookie 复用登录：扫码一次，登录态存入本地，开售瞬间不再走验证码流程，省掉 2000ms 以上的手工登录
• 快速模式（fast_mode）：默认开启，砍掉调试输出和冗余等待，订单确认页加载等待压到 2 秒
• 内置重试：max_retries默认 1000 次，票没放出就继续轮询，放出后自动进入选择流程

先记住这个判断：它的速度不来自魔法，来自"提前登录 + 短轮询 + 配置驱动选择"三件事。

上手前的 3 样准备

开工前备齐环境、账号、网络这三样，能避开 80% 的开售夜事故。

• 环境：Python 3.9+、最新版 Chrome；走移动端还要 Node.js 20.19.0+、Appium 3.1.0+ 和 Android 真机或模拟器
• 账号：大麦账号提前登录，观演人姓名逐字核对（含生僻字），这是实名购票的硬性前提
• 网络：优先有线连接，ping到 100ms 以内，开售前 1 小时禁用系统自动更新

装好仓库后，在项目根目录执行：

git clone https://gitcode.com/GitHub_Trending/ti/ticket-purchase cd ticket-purchase pip install -r damai/requirements.txt bash check_environment.sh

移动端路线再加一条：

bash start_appium.sh

环境检查脚本里任何一项标红，先修那一项再往下走。

从 0 到第一次成功运行

这一步的目标是"跑通"，不是"抢到"，全程约 10 分钟。

1. 跑环境自检。执行上面的check_environment.sh。看到 Python、Node.js、Appium、Android SDK 四项全部打勾，就算这一步通过；任何一项报错都直接指向下一步该装的东西。

2. 完成一次 Cookie 登录。首次运行 Web 端主程序 damai/damai.py 时，Chrome 会弹出让你扫码。扫码后登录态自动存为本地 Cookie 文件，此后每次启动直接加载，看到"完成cookie加载"字样即成功。

3. 写配置文件。编辑damai/config.json，把目标演出 URL、观演人、城市、日期、价格填进去（下一节有完整对照表）。程序启动时会校验必填字段，看到"配置文件加载成功"即通过。

4. 干跑一遍。先把if_commit_order设为false运行一次，观察程序能否自己选中城市、场次和票档。选对了，再把它改回true，第一次运行就算真正完成。

把配置改对，比手速更重要

配置是整套系统唯一需要你的决策输入，改错的代价就是开售夜白跑。先看参数对照表：

完整示例（以某巡回演唱会杭州站为例）：

{ "index_url": "https://www.damai.cn/", "login_url": "https://passport.damai.cn/login", "target_url": "https://detail.damai.cn/item.htm?id=1015510957565", "users": ["陈伟成", "李晓婷"], "city": "杭州", "dates": ["2026-04-11", "2026-04-12"], "prices": ["680", "880"], "if_listen": true, "if_commit_order": true, "max_retries": 10000 }

对照你自己的演出页面，逐字核对一遍city、dates、prices，再开始抢。

开售夜时间轴推演

拿一场 20:00 开售、多站巡演的演唱会推演一遍，你会知道每个时间段该干什么。

开售前 30 分钟：确认系统时间与 NTP 同步——本地时钟偏差 5 秒，就可能让你在"还没开售"时反复撞墙。此时程序已启动并加载 Cookie，Chrome 停留在详情页，元素选择器全部预热完毕。

开售瞬间：程序进入轮询循环，单次检查间隔约 80~150ms，按dates和prices的数组顺序匹配场次与票档。命中后进入订单确认页，page_load_delay等待约 2 秒加载完成。

开售后 10 秒内：if_commit_order为true时自动提交订单，页面停留 5 分钟等你完成支付——这 5 分钟是留给你的最后窗口，别切走。

开售前的全部准备都应该在 19:30 前完成，开售夜你不该再做任何配置动作。

成功率从 30% 到 80% 的 4 个开关

四个杠杆，每个都有可量化的阈值，按优先级从高到低拧。

🔌 网络：延迟比带宽重要，抢票请求走的是单连接。

• 换有线连接，关掉路由器上其他设备的更新下载
• 用固定 DNS（如 114.114.114.114），避开高峰期调度抖动
• 阈值：ping到站点 <50ms，波动 <10ms

参数：配置优先级顺序决定你"先抢什么"。

• dates和prices都写满备选，热门场次首选票档常在前 2 秒被抢光
• max_retries拉到 10000，覆盖开售延迟和重试窗口
• 阈值：轮询单轮间隔不超过 150ms，再低只会增加封禁风险

重试与并发：别开 4 个窗口同时抢，同一个 Cookie 多端并发反而容易触发风控。

• 一台设备、一个引擎跑满，失败换引擎而不是加窗口
• 阈值：并发实例数 = 1

行为模拟：程序已内置部分反检测参数，你只需要别破坏它。

• 启动参数已排除enable-automation标记并禁用AutomationControlled特征
• 保留 Cookie 登录方式，不要在开售夜现场扫码
• 阈值：登录态复用成功率应为 100%，出现一次扫码即说明 Cookie 失效，立即换

把ping值、轮询间隔、并发数这三个数字写在开售夜的便签上，出问题时先看它们。

翻车急救手册

三个高频故障，统一按"现象 → 最可能原因 → 处理动作"处理：

急救的第一原则：先看报错文本，再动任何配置，别在开售夜里边猜边改。

合规边界

仅限个人购票使用，观演人与本人及亲友实名一致；遵守平台用户协议，不用于倒卖、不批量多账号并发；自动化工具可能违反平台条款并导致账号风险，使用前自行评估。

二次开发路线图

想往里加东西，先看这 4 个文件：

• damai/damai.py：Web 端入口，负责配置校验与流程编排
• damai/concert.py：核心抢票逻辑，页面选择与下单都在这里
• damai/config.py：配置类定义，加参数从这里入手
• damai_appium/damai_app_v2.py：移动端优化版实现

三条扩展方向，由易到难：

• 加抢票结果通知（邮件或消息推送），在下单成功分支后挂一个钩子
• 把轮询间隔和重试次数做成按时间衰减策略，开售瞬间加密、放票后放缓
• 给移动端加多票源对比，同一场次同时监听 App 与网页的库存状态

先挑一条最小改动（通知钩子）动手，跑通再谈其余两条。

先把if_commit_order设成false，找一场冷门小型演出完整走一遍流程。 每个环节的耗时记下来，这就是你开售夜的底牌。 祝你顺利入座。

【免费下载链接】ticket-purchase大麦自动抢票，支持人员、城市、日期场次、价格选择项目地址: https://gitcode.com/GitHub_Trending/ti/ticket-purchase