基于Python与Appium的票务自动化抢票开源工具实战3步告别手速焦虑【免费下载链接】ticket-purchase大麦自动抢票支持人员、城市、日期场次、价格选择项目地址: https://gitcode.com/GitHub_Trending/ti/ticket-purchase热门演唱会开票那一秒你盯着倒计时疯狂点立即购买页面转圈、报错、售罄——隔壁用自动抢票工具的人已经进入支付页了。这不是手速问题是思路问题。本文要介绍的ticket-purchase项目就是一套用 Python 抢票脚本 Selenium Appium 打通的票务自动化方案Web 端和 Android 移动端都能跑支持精确到城市、日期、票档、观演人的全链路自动下单。下面我们用问题—解法—实战的节奏从环境搭建到跑通第一单一步步讲清楚它是怎么工作的。痛点清单抢票失败的 N 种姿势先别急着看代码对照下面这份清单看看你中了几条痛点典型场景脚本怎么化解手速不够开售 1 秒内票被清空毫秒级坐标点击不等人眼反应流程太长选城市→选日期→选票档→选人数→提交一次脚本把整条链路串起来反复刷新盯着缺货登记按钮手动刷新轮询检测自动刷新重试多账号一个人要抢多个观演人批量勾选观演人名单回流票退票不定时放出错过就没了监听模式后台持续盯梢一句话要点这套工具把人在浏览器/App 里手动完成的十几次点击压缩成了配置文件里的一小段 JSON 和一条启动命令。先认识两个引擎Selenium 与 Appium项目分两个入口对应两套不同的自动化引擎源码目录也很清晰官方文档README.mdWeb 端源码damai/移动端源码damai_appium/启动与环境脚本check_environment.sh、start_appium.sh、start_ticket_grabbing.shWeb 端Selenium用 ChromeDriver 驱动真实 Chrome 浏览器模拟登录、扫码、点击、选票。它的核心价值是Cookie 复用——第一次扫码登录后把 Cookie 序列化存成本地文件下次直接加载省掉重复登录。移动端Appium UiAutomator2Appium 是跨平台移动自动化框架UiAutomator2 是它在 Android 上的底层驱动。脚本直接对大麦 App里的界面元素下发指令连真机或模拟器都能控制。相比 Web 端移动端胜在快——下面会看到它对每个点击动作都做了极致的性能裁剪。整个抢票流程可以浓缩成下面这张图第 1 步环境体检5 分钟确认万事俱备搭建 Python 抢票脚本环境最怕装到一半才发现少个组件。项目自带一键体检脚本把常见坑提前排掉./check_environment.sh它会逐项核对五件事Python 版本是否 3.9Web 端和移动端通用Node.js 是否 20.19.0Appium 3.1.0 的运行前提Appium 是否已安装、是否装了 uiautomator2 驱动ANDROID_HOME/ANDROID_SDK_ROOT环境变量是否指向 SDKadb devices能否看到设备、设备上是否已装大麦 App包名cn.damai、4723 端口的 Appium 服务是否在跑一句话要点体检脚本的输出顺序就是你的安装顺序看到 ❌ 的那一行就是当前最该处理的问题。手动补齐依赖的常用命令长这样# 安装 Python 依赖移动端和 Web 端通用 pip install -r damai/requirements.txt # 安装 Appium 与 Android 驱动 npm install -g appium appium driver install uiautomator2 # 写入 Android 环境变量macOS / Linux写入 ~/.bashrc 或 ~/.zshrc export ANDROID_HOME/path/to/android/sdk export ANDROID_SDK_ROOT/path/to/android/sdk为什么要把环境检查前置抢票是强时效操作开票前 5 分钟才慌慌张张找问题等于把成败交给运气。体检脚本的作用就是把运行时才发现变成运行前就暴露。环境就绪后开一个终端启动 Appium./start_appium.sh脚本会再次校验 Node、设备、App 是否到位然后前台拉起appium --port 4723。留着一个终端给它别关。第 2 步看懂配置文件逐字段对照页面移动端的全部抢票参数都集中在damai_appium/config.jsonc。打开它你会看到类似下面的结构{ server_url: http://127.0.0.1:4723, keyword: 五月天, users: [林一, 陈默], city: 杭州, date: 05.20, price: 看台555元, price_index: 2, if_commit_order: true }一句话要点配置的本质是告诉脚本在页面上找什么、点哪里所以每一项都要和你即将面对的那个演出详情页逐一对照。下面是逐字段对照表建议照着页面现场核对配置项作用对应页面元素填写提醒server_urlAppium 服务地址无需页面对应默认http://127.0.0.1:4723keyword演出关键词搜索框填完整演出名减少歧义city目标城市城市切换弹窗里的城市项与 App 内显示完全一致date场次日期场次卡片上的日期按页面显示的格式填如05.20price票档描述票价区域可填看台555元这类页面原文price_index票档在列表里的序号票价 FrameLayout 索引从 0 开始是脚本定位的关键users观演人名单观演人勾选列表必须和 App 已录入的真实姓名一字不差if_commit_order是否自动提交订单提交按钮想试运行就设false配置界面长这样改完记得保存price_index为什么单独拎出来讲因为很多票档在页面上的文字是隐藏的界面渲染为了样式把文字清空了按文本反而找不到。脚本采用在票价容器内按 index 定位可点击 FrameLayout的策略所以这个序号填错票价就选错。建议先用小场次试运行几次确认 index 准确。把配置和真实页面放在一起对照理解会直观得多Web 端的配置文件damai/config.json结构略有不同重点是target_url目标演出链接、city、dates、prices以及两个开关if_listen是否监听回流票和fast_mode是否开启快速模式。逻辑大同小异本文以移动端为主线。第 3 步跑通你的第一单配置就绪、Appium 在跑、设备上已经打开大麦 App 并进入目标演出详情页这时候启动主脚本./start_ticket_grabbing.sh脚本会先做两件事用curl探一下http://127.0.0.1:4723/status确认 Appium 活着再读一遍config.jsonc并把当前关键词、城市、观演人打印出来给你复核。输入y确认后真正的工作才开始。一句话要点第一次运行建议把if_commit_order设为false只走选票不提交确认整条链路都能点通再开启全自动。移动端主程序的核心类在damai_appium/damai_app_v2.py主流程run_ticket_grabbing()按下面顺序执行选择城市 → 点击预约/购买按钮 → 按 price_index 选票档 → 按人数点号 → 点击确定购买 → 批量勾选观演人 → 提交订单每一步都有主方案 备用方案双保险。比如找预约按钮脚本会先按控件 ID 找找不到就按文本正则.*预约.*|.*购买.*找再不行换 XPath 用contains匹配。城市和提交按钮同理每个环节都准备了几套选择器轮番尝试。深入抢票脚本凭什么能抢到票抛开流程真正的技术含量集中在三个设计上这也是项目名里高性能三个字的来源。1. 超快点击坐标点击 手势指令看ultra_fast_click这个方法拿到元素后不调用常规的.click()而是先算元素矩形中心点坐标再通过 Appium 的mobile: clickGesture手势指令直接点点击时长压到 50 毫秒。这比等待元素可点击→滚动到可视→Selenium 点击的传统路径少了好几层网络往返。rect el.rect x rect[x] rect[width] // 2 y rect[y] rect[height] // 2 self.driver.execute_script(mobile: clickGesture, {x: x, y: y, duration: 50})2. 等待策略能不等就不等_setup_driver里有一组非常激进的设置waitForIdleTimeout设为 0意思是 UiAutomator2 不等页面空闲就立刻返回元素显式等待超时从常规的 5 秒压到 2 秒个别关键点击甚至只给 1.5 秒。每一步都在和页面流畅加载抢时间。3. 重试机制失败不是终点主入口run_with_retry把整个抢票流程包了一层循环默认最多尝试 3 次每次失败后先关掉驱动再重新初始化避免残留状态影响下一轮。Web 端的max_retries默认 1000 次则更多用于开售前反复刷新等待的场景——页面只要显示缺货登记就刷新重来直到按钮变成立即购买。让成功率再高一点的调优技巧技术之外环境本身的优化同样关键而且这几条成本几乎为零# 关闭 Android 系统动画减少渲染开销 adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0其他实用建议网络优先有线 Wi-Fi开票前用ping测一次到目标站点的延迟时间同步设备系统时间与北京时间校准差一秒都可能错过开售降低负载抢票期间关闭后台下载、视频等占带宽的程序先用小场次演练拿一场冷门演出完整跑一遍流程验证配置和选择器全部有效观察控制台脚本每一步都有中文日志比如成功找到 2 个用户票价选择失败启动备用方案这些输出是排障的第一手资料三种实战打法预售、回流、多设备打法一开售瞬间冲刺预售抢票适用于确定时间点开售的热门场次。开票前 30 分钟做环境体检前 10 分钟完成登录验证前 5 分钟让页面停在详情页开票瞬间脚本开始轮询。此场景建议开fast_mode拉高max_retries。打法二回流票监听不定时放票对应 Web 端配置里的if_listen: true。逻辑非常简单循环检测购票按钮的状态——是立即购买就执行购票流程并退出是缺货登记就继续等下一轮遇到网络异常就按间隔重试。适合捡漏但要注意监听间隔别设太短避免对服务器造成压力。打法三多设备协同极高热度场次一台主力设备开快速模式主攻一台备用设备开标准模式兜底第三台专跑监听。多设备意味着多账号、多路径成功率是乘法关系但请一定使用你自己的合规账号。常见报错速查表报错信息含义处理办法Node version must be at least ^20.19.0Node 版本过低用 nvm 装 20.19.0Neither ANDROID_HOME nor ANDROID_SDK_ROOT was exportedSDK 环境变量缺失补写环境变量并source配置Unable to find an active device or emulator没检测到设备adb devices确认连接、USB 调试已开Connection refusedAppium 没起来curl http://127.0.0.1:4723/status确认 4723 端口超时未找到用户: xxx观演人名字对不上核对 App 内真实姓名与users完全一致票价选错price_index填错从 0 开始数票档顺序用小场次重试如果界面元素定位失败多半是大麦 App 更新改了控件结构可以查看damai_appium/app.md里的说明或用 Appium Inspector 重新抓取元素定位信息后更新选择器。写在最后合理使用才有长期价值最后必须强调ticket-purchase这类自动抢票工具适合技术学习、流程自动化研究和个人正常购票请务必遵守大麦网的服务条款用专门的小号测试控制请求频率不恶意刷票、不影响其他用户正常购票。工具只是把流程自动化它不能也不应替你做出违反规则的选择。上手路径总结git clone https://gitcode.com/GitHub_Trending/ti/ticket-purchase cd ticket-purchase ./check_environment.sh # 1. 环境体检 ./start_appium.sh # 2. 启动 Appium # 3. 编辑 damai_appium/config.jsonc 填入你的演出参数 ./start_ticket_grabbing.sh # 4. 确认配置后开始抢票从手速拼不过别人到用脚本把流程跑通本质上是从被动等待到主动设计的一次转变。把这套流程吃透你收获的不仅是更高的购票成功率更是一整套 Web/移动端自动化的实战经验——这才是比门票更值钱的东西。【免费下载链接】ticket-purchase大麦自动抢票支持人员、城市、日期场次、价格选择项目地址: https://gitcode.com/GitHub_Trending/ti/ticket-purchase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于Python与Appium的票务自动化抢票开源工具实战：3步告别手速焦虑
基于Python与Appium的票务自动化抢票开源工具实战3步告别手速焦虑【免费下载链接】ticket-purchase大麦自动抢票支持人员、城市、日期场次、价格选择项目地址: https://gitcode.com/GitHub_Trending/ti/ticket-purchase热门演唱会开票那一秒你盯着倒计时疯狂点立即购买页面转圈、报错、售罄——隔壁用自动抢票工具的人已经进入支付页了。这不是手速问题是思路问题。本文要介绍的ticket-purchase项目就是一套用 Python 抢票脚本 Selenium Appium 打通的票务自动化方案Web 端和 Android 移动端都能跑支持精确到城市、日期、票档、观演人的全链路自动下单。下面我们用问题—解法—实战的节奏从环境搭建到跑通第一单一步步讲清楚它是怎么工作的。痛点清单抢票失败的 N 种姿势先别急着看代码对照下面这份清单看看你中了几条痛点典型场景脚本怎么化解手速不够开售 1 秒内票被清空毫秒级坐标点击不等人眼反应流程太长选城市→选日期→选票档→选人数→提交一次脚本把整条链路串起来反复刷新盯着缺货登记按钮手动刷新轮询检测自动刷新重试多账号一个人要抢多个观演人批量勾选观演人名单回流票退票不定时放出错过就没了监听模式后台持续盯梢一句话要点这套工具把人在浏览器/App 里手动完成的十几次点击压缩成了配置文件里的一小段 JSON 和一条启动命令。先认识两个引擎Selenium 与 Appium项目分两个入口对应两套不同的自动化引擎源码目录也很清晰官方文档README.mdWeb 端源码damai/移动端源码damai_appium/启动与环境脚本check_environment.sh、start_appium.sh、start_ticket_grabbing.shWeb 端Selenium用 ChromeDriver 驱动真实 Chrome 浏览器模拟登录、扫码、点击、选票。它的核心价值是Cookie 复用——第一次扫码登录后把 Cookie 序列化存成本地文件下次直接加载省掉重复登录。移动端Appium UiAutomator2Appium 是跨平台移动自动化框架UiAutomator2 是它在 Android 上的底层驱动。脚本直接对大麦 App里的界面元素下发指令连真机或模拟器都能控制。相比 Web 端移动端胜在快——下面会看到它对每个点击动作都做了极致的性能裁剪。整个抢票流程可以浓缩成下面这张图第 1 步环境体检5 分钟确认万事俱备搭建 Python 抢票脚本环境最怕装到一半才发现少个组件。项目自带一键体检脚本把常见坑提前排掉./check_environment.sh它会逐项核对五件事Python 版本是否 3.9Web 端和移动端通用Node.js 是否 20.19.0Appium 3.1.0 的运行前提Appium 是否已安装、是否装了 uiautomator2 驱动ANDROID_HOME/ANDROID_SDK_ROOT环境变量是否指向 SDKadb devices能否看到设备、设备上是否已装大麦 App包名cn.damai、4723 端口的 Appium 服务是否在跑一句话要点体检脚本的输出顺序就是你的安装顺序看到 ❌ 的那一行就是当前最该处理的问题。手动补齐依赖的常用命令长这样# 安装 Python 依赖移动端和 Web 端通用 pip install -r damai/requirements.txt # 安装 Appium 与 Android 驱动 npm install -g appium appium driver install uiautomator2 # 写入 Android 环境变量macOS / Linux写入 ~/.bashrc 或 ~/.zshrc export ANDROID_HOME/path/to/android/sdk export ANDROID_SDK_ROOT/path/to/android/sdk为什么要把环境检查前置抢票是强时效操作开票前 5 分钟才慌慌张张找问题等于把成败交给运气。体检脚本的作用就是把运行时才发现变成运行前就暴露。环境就绪后开一个终端启动 Appium./start_appium.sh脚本会再次校验 Node、设备、App 是否到位然后前台拉起appium --port 4723。留着一个终端给它别关。第 2 步看懂配置文件逐字段对照页面移动端的全部抢票参数都集中在damai_appium/config.jsonc。打开它你会看到类似下面的结构{ server_url: http://127.0.0.1:4723, keyword: 五月天, users: [林一, 陈默], city: 杭州, date: 05.20, price: 看台555元, price_index: 2, if_commit_order: true }一句话要点配置的本质是告诉脚本在页面上找什么、点哪里所以每一项都要和你即将面对的那个演出详情页逐一对照。下面是逐字段对照表建议照着页面现场核对配置项作用对应页面元素填写提醒server_urlAppium 服务地址无需页面对应默认http://127.0.0.1:4723keyword演出关键词搜索框填完整演出名减少歧义city目标城市城市切换弹窗里的城市项与 App 内显示完全一致date场次日期场次卡片上的日期按页面显示的格式填如05.20price票档描述票价区域可填看台555元这类页面原文price_index票档在列表里的序号票价 FrameLayout 索引从 0 开始是脚本定位的关键users观演人名单观演人勾选列表必须和 App 已录入的真实姓名一字不差if_commit_order是否自动提交订单提交按钮想试运行就设false配置界面长这样改完记得保存price_index为什么单独拎出来讲因为很多票档在页面上的文字是隐藏的界面渲染为了样式把文字清空了按文本反而找不到。脚本采用在票价容器内按 index 定位可点击 FrameLayout的策略所以这个序号填错票价就选错。建议先用小场次试运行几次确认 index 准确。把配置和真实页面放在一起对照理解会直观得多Web 端的配置文件damai/config.json结构略有不同重点是target_url目标演出链接、city、dates、prices以及两个开关if_listen是否监听回流票和fast_mode是否开启快速模式。逻辑大同小异本文以移动端为主线。第 3 步跑通你的第一单配置就绪、Appium 在跑、设备上已经打开大麦 App 并进入目标演出详情页这时候启动主脚本./start_ticket_grabbing.sh脚本会先做两件事用curl探一下http://127.0.0.1:4723/status确认 Appium 活着再读一遍config.jsonc并把当前关键词、城市、观演人打印出来给你复核。输入y确认后真正的工作才开始。一句话要点第一次运行建议把if_commit_order设为false只走选票不提交确认整条链路都能点通再开启全自动。移动端主程序的核心类在damai_appium/damai_app_v2.py主流程run_ticket_grabbing()按下面顺序执行选择城市 → 点击预约/购买按钮 → 按 price_index 选票档 → 按人数点号 → 点击确定购买 → 批量勾选观演人 → 提交订单每一步都有主方案 备用方案双保险。比如找预约按钮脚本会先按控件 ID 找找不到就按文本正则.*预约.*|.*购买.*找再不行换 XPath 用contains匹配。城市和提交按钮同理每个环节都准备了几套选择器轮番尝试。深入抢票脚本凭什么能抢到票抛开流程真正的技术含量集中在三个设计上这也是项目名里高性能三个字的来源。1. 超快点击坐标点击 手势指令看ultra_fast_click这个方法拿到元素后不调用常规的.click()而是先算元素矩形中心点坐标再通过 Appium 的mobile: clickGesture手势指令直接点点击时长压到 50 毫秒。这比等待元素可点击→滚动到可视→Selenium 点击的传统路径少了好几层网络往返。rect el.rect x rect[x] rect[width] // 2 y rect[y] rect[height] // 2 self.driver.execute_script(mobile: clickGesture, {x: x, y: y, duration: 50})2. 等待策略能不等就不等_setup_driver里有一组非常激进的设置waitForIdleTimeout设为 0意思是 UiAutomator2 不等页面空闲就立刻返回元素显式等待超时从常规的 5 秒压到 2 秒个别关键点击甚至只给 1.5 秒。每一步都在和页面流畅加载抢时间。3. 重试机制失败不是终点主入口run_with_retry把整个抢票流程包了一层循环默认最多尝试 3 次每次失败后先关掉驱动再重新初始化避免残留状态影响下一轮。Web 端的max_retries默认 1000 次则更多用于开售前反复刷新等待的场景——页面只要显示缺货登记就刷新重来直到按钮变成立即购买。让成功率再高一点的调优技巧技术之外环境本身的优化同样关键而且这几条成本几乎为零# 关闭 Android 系统动画减少渲染开销 adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0其他实用建议网络优先有线 Wi-Fi开票前用ping测一次到目标站点的延迟时间同步设备系统时间与北京时间校准差一秒都可能错过开售降低负载抢票期间关闭后台下载、视频等占带宽的程序先用小场次演练拿一场冷门演出完整跑一遍流程验证配置和选择器全部有效观察控制台脚本每一步都有中文日志比如成功找到 2 个用户票价选择失败启动备用方案这些输出是排障的第一手资料三种实战打法预售、回流、多设备打法一开售瞬间冲刺预售抢票适用于确定时间点开售的热门场次。开票前 30 分钟做环境体检前 10 分钟完成登录验证前 5 分钟让页面停在详情页开票瞬间脚本开始轮询。此场景建议开fast_mode拉高max_retries。打法二回流票监听不定时放票对应 Web 端配置里的if_listen: true。逻辑非常简单循环检测购票按钮的状态——是立即购买就执行购票流程并退出是缺货登记就继续等下一轮遇到网络异常就按间隔重试。适合捡漏但要注意监听间隔别设太短避免对服务器造成压力。打法三多设备协同极高热度场次一台主力设备开快速模式主攻一台备用设备开标准模式兜底第三台专跑监听。多设备意味着多账号、多路径成功率是乘法关系但请一定使用你自己的合规账号。常见报错速查表报错信息含义处理办法Node version must be at least ^20.19.0Node 版本过低用 nvm 装 20.19.0Neither ANDROID_HOME nor ANDROID_SDK_ROOT was exportedSDK 环境变量缺失补写环境变量并source配置Unable to find an active device or emulator没检测到设备adb devices确认连接、USB 调试已开Connection refusedAppium 没起来curl http://127.0.0.1:4723/status确认 4723 端口超时未找到用户: xxx观演人名字对不上核对 App 内真实姓名与users完全一致票价选错price_index填错从 0 开始数票档顺序用小场次重试如果界面元素定位失败多半是大麦 App 更新改了控件结构可以查看damai_appium/app.md里的说明或用 Appium Inspector 重新抓取元素定位信息后更新选择器。写在最后合理使用才有长期价值最后必须强调ticket-purchase这类自动抢票工具适合技术学习、流程自动化研究和个人正常购票请务必遵守大麦网的服务条款用专门的小号测试控制请求频率不恶意刷票、不影响其他用户正常购票。工具只是把流程自动化它不能也不应替你做出违反规则的选择。上手路径总结git clone https://gitcode.com/GitHub_Trending/ti/ticket-purchase cd ticket-purchase ./check_environment.sh # 1. 环境体检 ./start_appium.sh # 2. 启动 Appium # 3. 编辑 damai_appium/config.jsonc 填入你的演出参数 ./start_ticket_grabbing.sh # 4. 确认配置后开始抢票从手速拼不过别人到用脚本把流程跑通本质上是从被动等待到主动设计的一次转变。把这套流程吃透你收获的不仅是更高的购票成功率更是一整套 Web/移动端自动化的实战经验——这才是比门票更值钱的东西。【免费下载链接】ticket-purchase大麦自动抢票支持人员、城市、日期场次、价格选择项目地址: https://gitcode.com/GitHub_Trending/ti/ticket-purchase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考