biliTickerBuy 使用教程：Python 驱动的 B站会员购抢票自动化，开售瞬间自动下单-开发者社区

biliTickerBuy 使用教程：Python 驱动的 B站会员购抢票自动化，开售瞬间自动下单

【免费下载链接】WSABuildsRun Windows Subsystem For Android on your Windows 10 and Windows 11 PC using prebuilt binaries with Google Play Store (MindTheGapps) and/or Magisk or KernelSU (root solutions) built in.项目地址: https://gitcode.com/GitHub_Trending/ws/WSABuilds

biliTickerBuy 是一款基于 Python 的 B站会员购抢票工具，把下单请求的发出时间与服务器对齐后自动提交，面向受限于手速的普通用户，核心价值是将抢票从拼反应变成拼提前配置。

页面卡死与瞬间售罄：自动下单解决什么

开售时刻手指连续点击刷新，页面从卡顿到白屏，等接口返回时库存数已经归零——这是手动抢票的典型失败链路：人的点击永远比不出队列里第一批请求。biliTickerBuy 做的事情只有一件：配置完成后，在开售时间点自动发出下单请求，把“反应”从流程里拿掉。

开抢前的一次性准备

安装与验证

打开终端执行安装命令：

pip install bilitickerbuy

安装过程会一并注册btb命令，之后在终端运行btb --version，能打印版本号即代表环境就绪。

Cookie 的 4 步获取法

Cookie 相当于工具的“门禁卡”，请求带着它才能以登录态通过会员购的校验。获取步骤：

在浏览器中打开 B站并完成登录；
按 F12 打开开发者工具；
切换到 Application（或 Storage）面板，展开当前站点的 Cookie 列表；
全选并复制 Cookie 字段的内容。

安全提醒：Cookie 与登录态一一对应，只存放在本地配置里，不要贴到任何公开位置。

定位 project_id 与 sku_id

两个 ID 决定“买什么”，缺一个请求就会打到错误的对象上。类比地址：project_id 是楼栋号，sku_id 是楼里的门牌号，只有两者齐全才能精确到一件商品。

project_id：商品页 URL 中直接带有，打开 B站会员购商品页从地址栏读取即可；
sku_id：不在地址栏，需要在开发者工具的 Network 面板里刷新商品页，从返回商品信息的请求参数中取值。

从图形界面到命令行：跑通第一次

图形界面：5 步填完配置

在终端执行btb，网页界面自动打开，按顺序完成：

粘贴上一步复制的 Cookie；
填入 project_id 与 sku_id；
填写开售时间；
选择通知渠道；
点击开始。

启动后不再需要盯屏：程序在开售时间点发出下单请求，是否抢到的结果会通过第 4 步配置的渠道推送到手机。

命令行：一条命令加三个参数

不打开网页也能跑，命令如下：

btb buy config.json --interval 500

常用参数：

--interval 500：请求间隔 500 毫秒，控制轮询节奏；
--time_start "20:00"：手动指定开售时间，优先于配置文件；
--notify bark：直接指定通知渠道。

图形界面与命令行启动后的状态一致，等待推送结果即可。

NTP 对时、间隔控制与重试：成功率从哪来

手动抢票的失败大多发生在“到达时机”上，对应的设计手段有四处：

NTP 时间同步：持续向 NTP 源校准本地时钟，开售时刻按同步后的时间计算发送时机，消除本地时钟偏快或偏慢带来的误差。时间填写支持三种形式：ISO 格式（如 2024-12-31T20:00:00）、简写 20:00（默认当天）、精确到秒的 20:00:30；
间隔控制：请求按固定间隔发出，节奏接近正常用户操作，避免高频请求触发风控；
重试与日志：单次请求失败不会中断流程，最多自动重试 5 次，每一步的响应都会写入项目 log 目录下的日志文件，便于事后核对；
四种通知渠道：
- Bark：推送到 iOS 设备，支持自定义声音；
- Server酱：通过微信送达，对国内网络环境友好；
- PushPlus：覆盖微信、钉钉等多端；
- Ntfy：开源免费，可自建服务器。

四个目录看懂代码结构

项目按职责拆成四个目录，要改行为时先看对应位置：

interface/：用户界面与配置管理，interface/config.py 负责配置文件校验与加载，execution.py 是任务执行入口；
app_cmd/：命令行功能，buy.py 是btb buy的入口，ticker.py 负责定时任务；
task/：核心抢票逻辑，task/buy.py 是下单请求的主流程，endpoint.py 管理 B站 API 端点；
util/：通用工具，BiliRequest.py 封装请求发送，util/Notifier.py 实现上述四种通知，CookieManager.py 管理凭证。

开售前的 6 项检查清单

开售前提前 30 分钟启动程序，让时间同步和配置校验先跑完；
用真实配置完整跑一遍启动流程，确认无报错、ID 与 Cookie 粘贴完整；
有多账号条件时，为每个账号单独配置实例并行抢购；
网络优先有线连接，关掉下载、视频流等占带宽的进程；
手动校准一次系统时间，作为 NTP 同步之外的双保险；
检查通知渠道配置项已填写完整，避免抢到票却收不到推送。

常见卡点：报错与排查

现象：请求持续返回未登录→ 原因：Cookie 过期或复制不完整 → 解法：浏览器重新登录后按 4 步法重新复制，粘贴时注意首尾完整。
现象：找不到 sku_id→ 原因：sku 参数不在页面展示层，只出现在接口请求里 → 解法：在 Network 面板刷新商品页，筛选包含 sku 的请求，在请求负载中取值。
现象：想同时抢两件商品→ 原因：单个实例只处理一个商品 → 解法：启动多个实例，各自指向不同的商品配置。
现象：过程出错但看不出原因→ 原因：终端输出被滚动覆盖 → 解法：查看项目 log 目录下的日志文件，请求与重试记录都在其中。