简介面向哔哩哔哩会员购漫展抢票场景的自动化脚本项目采用图形化界面与纯接口设计集成验证码预演练习功能适合具备编程基础并希望掌握抢票流程或验证码识别技术的开发者学习使用。压缩包共六十六个文件大小十九点五四兆字节以源码脚本为主辅以样例、配置、说明文档并包含极验等验证码处理模块、容器化配置、仓库元数据等目录划分清晰。项目内封装有请求模块、订单二维码生成、消息推送工具及多个验证码识别示例同时附带测试文件用于功能验证。已有九十一人学习下载。资源不仅提供完整可运行的项目骨架还通过多样化的验证器与调试样例帮助读者理解接口交互、会话管理和验证码识别等关键环节便于二次开发或作为接口自动化学习的练习项目。1. 抢票脚本抢的不是票是接口时序B站会员购纯接口路线拆解做过抢票脚本的人都知道真正难的不是“手速”而是把登录态、场次信息、验证码全部前置准备好然后在开售瞬间只提交一个订单请求。B站会员购的漫展票务走的是典型的 Web 接口下单链路纯接口脚本不做浏览器模拟直接用 HTTP 请求跟服务端打交道比 Selenium 那套轻一个量级响应快、可控性强也更容易做成图形化工具。这个标题里的“验证码预演练习项目”本质就是把最容易翻车的一环——验证码识别与模拟提交——从真实抢票流程里剥离出来先跑通链路再谈其他。这篇文章适合想学接口调用、签名处理和 GUI 工程化的从业者也适合拿这个练习项目当接口编程练手的人。前提是把它当学习项目不要拿去干扰正常购票秩序。2. 会员购下单链路与关键参数摸清接口才能写脚本2.1 会员购票务下单的四个阶段B站会员购里的漫展票务下单流程可以拆成四个阶段拉取展会信息与场次列表选中具体场次和票档携带实名信息、收货方式提交订单验证码校验与支付跳转。纯接口脚本只关心第 2 到第 4 步。第 1 步通常在图形化界面里提前完成把场次号和票档号塞进配置文件开售瞬间不需要再拉一次列表减少一次往返就少一分延迟。常见做法是先用浏览器登录 B 站打开开发者工具F12的 Network 面板手动走一遍“进入会员购 → 选场次 → 选票档 → 提交订单”的操作把每一步的请求路径、请求头、表单参数记录下来。这个动作是整个练习项目的地基后面所有代码里的 URL 和参数名都来自这次抓包标题里说的“纯接口”指的就是这一套东西。我一般会把抓到的请求按时间顺序整理成一张表阶段请求作用关键参数场次列表获取可选场次展会ID、页码票档列表获取票价与余量场次ID提交订单创建订单票档ID、数量、实名信息验证码校验校验滑块/点选验证码token、轨迹数据抓包时注意勾选“Preserve log”避免页面跳转后请求记录被清空。这一步不需要写代码但决定了后面所有代码能不能跑通。2.2 纯接口方案的请求链与Session管理纯接口方案的核心是一个requests.Session。Session 会自动维持 cookie保证登录态在多次请求之间不丢。用代码描述最小请求链的话骨架是这样import requests # 全局会话自动携带 cookie保持登录态 session requests.Session() def build_headers(referer: str) - dict: return { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), Referer: referer, # 很多接口会校验 Referer务必从抓包里抄 Origin: https://member.bilibili.com, } def fetch_sessions(event_id: str, cookie_str: str): # 把浏览器里复制出来的完整 cookie 注入会话 session.headers.update({Cookie: cookie_str}) # 场次列表接口路径和参数以抓包结果为准 resp session.get( https://api.example.com/x/ticket/session/list, params{event_id: event_id, page: 1}, headersbuild_headers(https://member.bilibili.com/xxx), timeout5, ) # 先看状态码再看业务 code data resp.json() if data.get(code) ! 0: print(接口返回异常:, data.get(message)) return [] return data[data][list]逻辑说明先创建全局session把浏览器里的 cookie 复制进去这样后续请求都带着登录态。fetch_sessions负责拉场次列表URL 和参数必须替换成你自己抓到的真实值。示例里用api.example.com占位不是让你照抄——会员购的接口域名和路径会随版本调整练习项目最忌讳写死一组过期的 URL。参数说明headers里的Referer容易被忽略但很多接口靠它判断请求来源少了直接返回 403。timeout一定要显式设置默认情况下requests会无限等待开售瞬间服务端响应慢脚本会挂在那里不报错。2.3 鉴权参数与签名cookie、timestamp和sign会员购的部分接口不止要 cookie还要带签名参数。签名的作用是让服务端确认请求参数没有被篡改常见做法是把所有业务参数排序后拼上密钥做一次 MD5。一个通用签名函数长这样import hashlib import time def make_sign(params: dict, secret: str) - str: # 1. 过滤空值 items {k: v for k, v in params.items() if v is not None and v ! } # 2. 按 key 字典序拼接 raw .join(f{k}{items[k]} for k in sorted(items)) secret # 3. MD5 后转大写 return hashlib.md5(raw.encode(utf-8)).hexdigest().upper() def build_submit_params(ticket_id: str, count: int, ts: int) - dict: params { ticket_id: ticket_id, count: count, ts: str(ts), appkey: 从抓包里获取, } params[sign] make_sign(params, 从抓包里获取的签名密钥) return params逻辑说明make_sign的处理顺序是固定的——过滤空值、按 key 排序、拼接密钥、MD5。任何一步顺序不对服务端算出的签名就和本地不一致返回签名错误。参数说明appkey和密钥不要写在代码里到处贴练习项目里放到config.py或者本地环境变量。密钥来自抓包时看到的请求参数不同版本的客户端可能用不同的 appkey换一台设备抓到的可能都不一样。签名的意义是练习“参数防篡改”的思路不是为了绕过什么限制。注意接口路径、参数名、密钥都会变。跑不通时先重新抓包不要怀疑签名算法写错了——先核对参数名是否和抓包完全一致。3. 图形化界面从零搭用PyQt5把抢票脚本变成工具3.1 为什么选PyQt5而不是Tkinter纯接口脚本本身是命令行跑的但标题里明确要求“图形化”那就要选 GUI 框架。常见选择有 Tkinter、PyQt5、PySide6。Tkinter 是 Python 自带的胜在零依赖但做抢票工具这种需要“配置区 实时日志 状态提示”的界面它的控件样式偏老旧表格组件也简陋。PyQt5 的好处是控件齐全QTableWidget展示场次列表、QPlainTextEdit做日志输出、QFormLayout铺配置表单一套下来界面像样而且信号槽机制天然适合处理后台线程的回调。PySide6 是 Qt 官方绑定但网上资料和案例数量目前不如 PyQt5 多。练习项目优先选资料多的遇到问题搜得到答案比什么都重要。安装就一条命令pip install pyqt5 requests opencv-pythonopencv-python是给第 4 章的验证码预演用的如果只做 GUI 可以暂时不装。版本上 PyQt5 选 5.15 系列即可不需要追新。3.2 界面结构配置区、场次区、控制区、日志区图形化界面的布局我习惯分成四块从上到下依次排开配置区cookie、展会ID、票档ID、抢票数量场次区表格展示场次列表支持手动选择控制区开始抢票、停止、清空日志三个按钮日志区实时滚动输出请求日志。主窗口骨架from PyQt5.QtWidgets import ( QApplication, QWidget, QLabel, QLineEdit, QPushButton, QFormLayout, QVBoxLayout, QTableWidget, QPlainTextEdit, QHBoxLayout ) class MainWindow(QWidget): def __init__(self): super().__init__() self.setWindowTitle(会员购抢票练习工具) self.resize(720, 620) # 配置区 form QFormLayout() self.cookie_edit QLineEdit() self.event_edit QLineEdit() self.count_edit QLineEdit(1) form.addRow(Cookie, self.cookie_edit) form.addRow(展会ID, self.event_edit) form.addRow(数量, self.count_edit) # 场次区 self.table QTableWidget(0, 3) self.table.setHorizontalHeaderLabels([场次ID, 名称, 余量]) # 控制区 self.start_btn QPushButton(开始抢票) self.stop_btn QPushButton(停止) self.clear_btn QPushButton(清空日志) btn_row QHBoxLayout() btn_row.addWidget(self.start_btn) btn_row.addWidget(self.stop_btn) btn_row.addWidget(self.clear_btn) # 日志区 self.log_view QPlainTextEdit() self.log_view.setReadOnly(True) # 总体布局 layout QVBoxLayout(self) layout.addLayout(form) layout.addWidget(self.table) layout.addLayout(btn_row) layout.addWidget(self.log_view) def append_log(self, msg: str): # 带时间戳写日志方便事后排查时序问题 from datetime import datetime line f[{datetime.now().strftime(%H:%M:%S.%f)[:-3]}] {msg} self.log_view.appendPlainText(line)逻辑说明界面本身不执行抢票逻辑只负责收集配置、展示状态、触发开始和停止。append_log是统一的日志入口所有业务代码通过它输出信息时间戳精确到毫秒后面排查“是不是提前了 200ms 发起请求”这类问题全靠它。参数说明Cookie 这个输入框要支持粘贴浏览器里的完整 cookie 字符串不要做成“用户名 密码”登录表单——纯接口路线不负责模拟登录登录态从浏览器复制过来是最简单可靠的方案。这也是为什么标题里写“纯接口”而不是“全自动登录”。3.3 抢票线程与界面分离QThread的正确用法新手最容易踩的坑是点击“开始抢票”后在按钮的 clicked 信号里直接跑 while 循环结果窗口立刻卡死鼠标转圈最终只能强杀进程。原因很简单——抢票循环是阻塞操作把它放在 GUI 主线程里Qt 的事件循环就被挡住了。正确做法是把抢票逻辑丢进QThread的子类通过信号把日志和结果传回主线程from PyQt5.QtCore import QThread, pyqtSignal class GrabWorker(QThread): log pyqtSignal(str) # 日志信号回传主线程 finished_order pyqtSignal(dict) # 订单结果信号 def __init__(self, config: dict): super().__init__() self.config config self._stop False def run(self): # 抢票循环在子线程里跑 while not self._stop: self.log.emit(f尝试提交订单票档 {self.config[ticket_id]}) # 这里调用第 2 章的请求函数 # result submit_order(self.config) # 成功后就发信号并退出 if True: # 示意条件 self.finished_order.emit({order_id: mock_order_001}) break def stop(self): self._stop True在主窗口里这样启动def start_grab(self): config { cookie: self.cookie_edit.text().strip(), event_id: self.event_edit.text().strip(), count: int(self.count_edit.text().strip()), } self.worker GrabWorker(config) self.worker.log.connect(self.append_log) self.worker.finished_order.connect(self.on_order_done) self.worker.start() def on_order_done(self, order: dict): self.append_log(f订单创建成功: {order[order_id]})逻辑说明GrabWorker继承QThreadrun()里是真正的抢票循环。pyqtSignal负责把子线程里的字符串和字典“搬运”到主线程connect指向界面上的日志函数和完成回调。因为信号槽默认是队列连接跨线程调用是安全的。参数说明stop()用一个布尔标志位实现协作式停止不要在窗口关闭时直接调terminate()那会中断正在进行的 HTTP 请求可能导致订单重复提交或者数据写坏。窗口关闭事件里应该先stop()再wait()等待线程退出。4. 验证码预演练习滑块识别、打码接入与测试边界4.1 会员购场景里会遇到的三类验证码B站会员购在提交订单阶段可能出现验证码常见的有三类滑块验证码、点选文字验证码、短信验证码。纯接口脚本里短信验证码无法自动处理因为要接收手机短信这块基本留给人工。点选文字验证码需要 OCR 或者深度学习模型练习成本偏高。滑块验证码是最适合做“预演练习”的——它图形特征明确本地就能做识别实验。标题里的“验证码预演练习项目”我理解就是这个意思不追求真实环境里的高通过率而是把“图片获取 → 缺口定位 → 滑动轨迹生成 → 校验提交”整条链路在本地跑通验证自己的代码逻辑有没有问题。4.2 滑块缺口定位模板匹配与边缘检测的预演滑块验证码的缺口定位最常用的本地方案是 OpenCV 的模板匹配拿一张“无缺口的背景图”当模板在“有缺口的背景图”里找差异位置。如果拿不到无缺口图就用边缘检测找出缺口轮廓。一个可以跑的预演示例import cv2 import numpy as np def find_gap_x(bg_path: str, gap_path: str) - int: # 背景图与滑块小图的缺口位置匹配 bg cv2.imread(bg_path, cv2.IMREAD_GRAYSCALE) gap cv2.imread(gap_path, cv2.IMREAD_GRAYSCALE) # 模板匹配计算左上角最佳匹配位置 result cv2.matchTemplate(bg, gap, cv2.TM_CCOEFF_NORMED) _, _, _, max_loc cv2.minMaxLoc(result) # 返回缺口中心 x 坐标y 方向一般不用管 h, w gap.shape[:2] return max_loc[0] w // 2 def generate_track(distance: int) - list: # 模拟人类滑动轨迹先快后慢带随机抖动 track [] current 0 mid distance * 0.7 while current distance: if current mid: step int(np.random.normal(12, 4)) else: step int(np.random.normal(4, 2)) step max(1, min(step, distance - current)) current step track.append(current) return track逻辑说明find_gap_x用模板匹配找到缺口在背景图中的位置返回的是位移距离。generate_track生成滑动轨迹轨迹的特点是先快后慢每一步长度带随机噪声这样比一次拖到位更像人手操作。参数说明TM_CCOEFF_NORMED是归一化相关系数匹配对光照变化不敏感滑块验证码里灰度图直接跑这个就行。track里的步长参数12、4不是定死的不同验证码的缺口距离和画幅比例不一样练习时先打印出distance的值再观察轨迹曲线确认没有一步跨过终点的情况。注意真实环境里验证码还会带时间戳和轨迹加密参数本地预演通过不代表线上能过。练习项目的价值在于把链路跑通而不是保证通过率。4.3 验证码预演模块的代码组织验证码这块代码别和 GUI 逻辑混在一起单独拆一个模块方便换算法、换打码平台。目录结构我习惯这样组织# 示意目录结构不包含具体文件内容 main.py # GUI 入口 grab_worker.py # 抢票线程 captcha/ __init__.py slider.py # 滑块定位与轨迹生成 platform.py # 打码平台接入预留 resources/ sample_bg.png # 预演用样例图片 sample_gap.pngplatform.py里可以预留一个打码平台接口的抽象层class CaptchaSolver: 统一验证码识别接口预演项目里用本地算法实现 def __init__(self, mode: str local): self.mode mode # local 或 platform def solve(self, bg_path: str, gap_path: str) - dict: if self.mode local: from captcha.slider import find_gap_x, generate_track distance find_gap_x(bg_path, gap_path) return {distance: distance, track: generate_track(distance)} else: # 打码平台的 HTTP 调用在这里实现仅用于测试 raise NotImplementedError(平台接入需要自行申请并配置密钥)逻辑说明CaptchaSolver做了本地算法和平台接入的隔离。练习项目默认走local用 OpenCV 跑通全流程platform分支留了口子以后真要接打码服务只需要在solve里加一个 HTTP 请求不影响上层调用代码。参数说明mode的取值放到配置文件里不要在代码里写死。预演项目的样例图片放在resources目录用相对路径加载避免换机器后路径失效。5. 图形化抢票避坑清单时间偏移、风控与订单丢失5.1 现象按钮点了脚本没反应控制台也没有日志原因多半是异常被吞了。GUI 程序里按钮的回调函数如果不做异常捕获任何报错都会直接打到 stderr而用pythonw.exe启动或打包成 exe 后stderr 是不可见的看起来就是“没反应”。解决在start_grab开头和GrabWorker.run里包一层 try/except把traceback.format_exc()直接写到日志区import traceback def start_grab(self): try: # ... 原有逻辑 pass except Exception: self.append_log(traceback.format_exc())血泪经验是任何回调函数都值得加这句兜底不要相信“我这个函数不会有异常”的想法。5.2 现象日志显示“提交成功”但订单列表里查不到先说结论你看到的“成功”多半是假成功。很多接口的 HTTP 状态码是 200但业务 code 不是 0而是“库存不足”“参数错误”“未实名”。脚本只看状态码就以为成功了订单自然不存在。解决提交订单后必须校验两层——HTTP 状态码是 200且 JSON 里的code 0并且能从data里取到订单号。取不到订单号一律视为失败把完整的响应体打出来resp session.post(url, dataparams, headersheaders) body resp.json() if body.get(code) ! 0: self.log.emit(f下单被拒: {body.get(message)}) return None order_id body[data][order_id] # 这里取不到就抛异常触发日志5.3 现象滑块识别结果正确提交后仍被拦截本地预演时缺口定位很准但真实提交总被拒原因通常在三个地方轨迹太假、验证码 token 过期、请求少了加密参数。第一个最容易被忽略——只传了滑到终点的x坐标没传轨迹数组或者轨迹数组是直线匀速的一眼就是机器。解决把generate_track生成的轨迹数组完整传给校验接口并且在校验前确认验证码图片和 token 是同一批次拿到的。预演练习里不要追求过真实风控把“识别 → 生成轨迹 → 提交 → 看反馈”这几步的日志打通知道每一站在哪失败就够了。5.4 现象开售前1秒开始抢反而被限流很多人把脚本改成在开售前 1 秒连续发 10 个请求结果被限流。原因有两个一是本地时钟和服务端时钟有偏差你以为的“开售前 1 秒”实际是“开售后 1 秒”二是瞬时高频请求直接触发风控真正的抢票不是拼请求数量而是拼单次请求的完整度。解决先做时间校准用一个时间接口取服务端时间算出本地偏移量import time, requests def server_offset_ms(session: requests.Session) - float: # 请求带 ts 参数服务端返回自己的时间戳 resp session.get(https://api.example.com/time, params{ts: int(time.time() * 1000)}) server_ms resp.json()[data][server_ms] return server_ms - time.time() * 1000 # 正数代表本地慢了拿到偏移量后所有“是否到点”的判断都用本地时间 offset。请求频率控制在开售瞬间发 1 到 2 个请求后面用退避重试别在同一毫秒打出一串请求。5.5 现象抢票过程中GUI卡死只能强杀进程界面卡死的根因在 3.3 节已经说过耗时操作放到了主线程。但还有一种隐蔽情况——子线程里直接用print打印日志或者子线程里调用了修改界面控件的代码Qt 跨线程操作控件会引发未定义行为表现就是偶发卡死。解决所有日志一律走QThread的信号回传子线程里绝不直接碰控件。字符串拼接和控件更新都在主线程的槽函数里做。这一点没有商量余地不是“碰巧没问题”就算过的。6. 让练习项目可自检报文回放、签名校验与日志分级6.1 用真实报文回放验证解析逻辑验证接口解析代码对不对最快的方式是把抓包得到的真实请求保存成离线用例然后写一个回放脚本# replay_check.py 示意 import json, requests with open(cases/submit_order_case.json, r, encodingutf-8) as f: case json.load(f) session requests.Session() session.headers.update(case[headers]) resp session.post( case[url], paramscase.get(params), datacase.get(data), timeout5, ) assert resp.status_code 200, f状态码异常: {resp.status_code} body resp.json() assert body.get(code) 0, f业务异常: {body} print(回放通过订单号:, body[data][order_id])回放的意义是不依赖真实开售时间不依赖真实库存随时验证代码解析逻辑有没有被改坏。我把每次抓包保存成一个 JSON 文件放进cases/目录跑回归测试时就逐个回放。6.2 签名校验与时间自检签名出错是最难排查的一类问题因为报错信息往往只是“sign error”。我的自检习惯是写一个独立脚本对同一组参数用代码算一遍签名再和抓包里的真实 sign 比对。如果算法和密钥都对结果应该完全一致。不一致就按“参数没过滤空值、排序不是字典序、密钥复制多了一个空格”这三个方向排查。6.3 日志分级与收尾练习项目的日志不要只分“成功/失败”两档。我一般分三级INFO记录每次请求的 URL、耗时、HTTP 状态码WARN记录重试、限流、验证码被拒ERROR记录抛异常和订单创建失败。GUI 日志区用颜色区分三档排查问题时一眼就能定位是哪一段链路出了问题。这个项目做完我最大的感受是抢票脚本的工程难点从来不在“发请求”而在“时序、状态管理和可观测性”。每次开售前我都会跑一遍报文回放确认签名、cookie、参数解析都没被改坏才敢把界面打开。图形化界面是给别人看的回放脚本和日志分级才是给自己留的后悔药。希望帮到你。本文还有配套的精品资源点击获取
