简介：这是一份围绕B站会员购漫展购票场景整理的图形化接口练习项目，面向希望了解自动化请求流程、验证码预演与桌面端交互实现的开发者，也可作为Python网络编程与GUI封装的参考案例。压缩包共66个文件，约19.54MB，以21个Python源码为核心，配合配置与依赖说明、Docker与工作流文件、示例文本及图标资源，覆盖登录、请求封装、验证码校验、订单二维码、配置管理与推送工具等模块，目录按功能拆分，便于按需阅读和调试。已有93人学习，说明该主题具有一定关注度。读者可从中梳理接口调用、Cookie管理、时间同步、验证码处理分支和错误捕获的组织方式，并借助test与sample内容理解运行流程；项目也保留了打包与容器化配置，适合做本地实验和代码结构分析。需注意，相关技术仅可用于合法合规的学习研究，实际使用应遵守平台规则与法律法规。

1. 从「一键抢到」到「四层拆解」：这个练习工程到底练什么

拿到这个压缩包时，我先看的是它的标题：图形化、纯接口、验证码预演。第一反应是又一份号称「一键抢到」的常见货色，但拆进目录就发现不是——它更像一个把预约下单拆成界面层、会话层、时序层、验证码层四段的练习工程，核心价值不在「抢」，在于把一件事拆成可观测、可回放、可改参数的模块。它解决的是做接口自动化时最先遇到的三类难题：cookie 怎么保活、开抢那一秒怎么对齐、图形验证码怎么在本地先跑通再上线。适合已经会写 requests、但没做过带 GUI 的时序程序的人；也适合手里那堆散装脚本想收拾成工程结构的人。下面我按目录、界面、链路、验证码、避坑五段把它拆开，代码都是能直接抄改的骨架，接口地址一律用占位符，实际要跑得自己抓包填，并且只在自己账号、低频前提下做验证。

2. 工程骨架与技术选型：从目录结构看清四层职责

这个工程最值得先看的是目录，不是代码。散装脚本通常一个文件几百行，抓包、拼接、发请求、打印日志全塞一起，改一个参数要翻半小时；这个工程把职责按「谁在什么时候需要它」切开，UI 只负责展示和收指令，核心链路只管发请求，验证码模块独立到可以脱离主程序单独跑。选型上也很务实：GUI 用 PyQt5 而不是 tkinter，因为要跨线程回传日志和状态，Qt 的信号槽机制能省掉一大半手写锁的麻烦；HTTP 层用 requests 同步调用而不是 aiohttp，因为真正卡精度的是对时和建连预热，不是并发数，同步模型调试起来一目了然。

2.1 目录结构：四层职责怎么切

拆包后主干大致是这样，我按自己的习惯重排了注释：

ticket-practice/ ├── app/ │ ├── main.py # 入口：读配置 -> 建 UI -> 装控制器 │ ├── ui/ │ │ ├── main_window.py # 主窗口、按钮、日志面板 │ │ └── widgets.py # 倒计时、状态灯这类小控件 │ ├── core/ │ │ ├── session.py # 会话、连接池、重试策略 │ │ ├── signer.py # 参数签名 │ │ ├── clock.py # 对时与开抢时刻计算 │ │ ├── order.py # 一次下单尝试的完整流程 │ │ └── limiter.py # 令牌桶限频 │ ├── captcha/ │ │ ├── preprocess.py # 灰度、放大、二值化、去噪 │ │ ├── solver.py # 识别后端（本地模型 / 打码服务） │ │ └── replay.py # 预演集回放与命中率统计 │ └── utils/ │ ├── config.py # 配置加载与校验 │ └── logger.py # 文件 + 界面双写 ├── tests/ │ └── test_signer.py ├── config.yaml └── requirements.txt

这个切法有个明显好处：captcha/完全不 importui/，意味着你可以写个脚本把预演集跑一万张，不用启动界面；core/clock.py也不依赖网络之外的任何东西，单测好写。我一般会把order.py里「发请求」和「解析结果」再拆成两个函数，因为前者要贴着时序改，后者要贴着接口字段改，改动频率完全不同，混在一起迟早出问题。

2.2 依赖清单与运行环境

依赖不多，但每一项都不是随便挑的：

# requirements.txt PyQt5 # 图形界面与跨线程信号 requests # 同步 HTTP，调试直观 urllib3 # 连接池与重试策略（requests 自带依赖，显式声明便于定制） PyYAML # 配置文件 opencv-python # 验证码预处理 ntplib # 简易 SNTP 对时

Python 版本建议 3.9 以上，因为用到了dataclasses的字段反射和一些类型标注写法。opencv-python只装主包就够，不需要 contrib，预演模块用的是最基础的阈值和形态学。虚拟环境建好之后pip install -r requirements.txt，第一次跑python -m app.main如果报qt.qpa.plugin: Could not load the Qt platform plugin，那是 Qt 动态库路径的问题，不是代码问题，重装一次PyQt5基本能解决；在无显示器的环境下调试时，记得设QT_QPA_PLATFORM=offscreen，否则界面根本没起来就退了。

2.3 配置与账号态：cookie 放哪儿、怎么校验

配置文件是整个工程唯一需要你手填的地方，也是踩坑最多的地方。我把用到的字段列一下：

加载与校验我会写成「早失败」的形式，宁可启动就崩，也不要等到开抢前 3 秒才发现少个字段：

from dataclasses import dataclass, fields import pathlib import yaml @dataclass class Config: cookie: str item_id: int sku_id: int buy_num: int open_time: str advance_ms: int salt: str referer: str = "https://example.com/" REQUIRED = ("cookie", "item_id", "sku_id", "open_time", "salt") def load_config(path: str = "config.yaml") -> Config: raw = yaml.safe_load(pathlib.Path(path).read_text(encoding="utf-8")) or {} missing = [k for k in REQUIRED if not raw.get(k)] if missing: # 缺字段直接抛，不设默认值兜底 raise ValueError(f"配置缺字段: {missing}") known = {f.name for f in fields(Config)} return Config(**{k: v for k, v in raw.items() if k in known})

这里的逻辑说明两点：一是missing只查必填项，advance_ms、referer这类有合理默认值的字段不进必填列表，避免每次都要抄一遍；二是known过滤掉配置文件里多余的键，防止你在 yaml 里写了拼错的字段名还以为生效了——这种问题最难查，程序不报错，但参数就是没传进去。参数调整上，advance_ms是最需要反复试的一个，从 100 到 500 之间找一个稳定值，别迷信「越早越好」，提前太多会被判异常请求，反而拿不到下单资格。

3. 图形化界面层：把「抢购」拆成可点的按钮和可看的日志

纯接口脚本最难受的地方是黑匣子：跑起来只有终端滚屏，出问题不知道卡在哪一步。图形化这一层不是为了好看，是为了把内部状态变成可见的时间线——倒计时在第几秒、当前是第几次尝试、上一次返回码是什么、验证码识别花了多少毫秒。这一章拆三件事：窗口怎么搭、工作线程怎么接、日志怎么回显。

3.1 主窗口布局与信号槽接线

主窗口只做三件事：摆控件、连信号、把控制器的接口挂到按钮上。关键约束是「UI 线程绝不发网络请求」，所有耗时动作都通过控制器的start/stop转交给工作线程。

from PyQt5.QtCore import QObject, pyqtSignal from PyQt5.QtWidgets import (QMainWindow, QWidget, QVBoxLayout, QHBoxLayout, QPushButton, QTextEdit, QLabel) class Bridge(QObject): """跨线程通信的唯一通道：工作线程 emit，UI 线程 connect 后自动排队回主线程""" log = pyqtSignal(str) state = pyqtSignal(str) countdown = pyqtSignal(int) class MainWindow(QMainWindow): def __init__(self, bridge: Bridge, ctrl): super().__init__() self.bridge = bridge self.ctrl = ctrl self.setWindowTitle("预约练习台 v0.1") self.resize(880, 560) self.lbl_state = QLabel("待机") self.btn_start = QPushButton("开始预演") self.btn_stop = QPushButton("停止") self.btn_stop.setEnabled(False) self.log_view = QTextEdit() self.log_view.setReadOnly(True) bar = QHBoxLayout() bar.addWidget(self.lbl_state) bar.addStretch(1) bar.addWidget(self.btn_start) bar.addWidget(self.btn_stop) root = QVBoxLayout() root.addLayout(bar) root.addWidget(self.log_view) holder = QWidget() holder.setLayout(root) self.setCentralWidget(holder) # 信号槽：只在主线程里碰控件 self.bridge.log.connect(self.log_view.append) self.bridge.state.connect(self.lbl_state.setText) self.btn_start.clicked.connect(self._on_start) self.btn_stop.clicked.connect(self._on_stop) def _on_start(self): self.btn_start.setEnabled(False) self.btn_stop.setEnabled(True) self.ctrl.start() def _on_stop(self): self.ctrl.stop() self.btn_start.setEnabled(True) self.btn_stop.setEnabled(False)

逻辑上要说明的是Bridge这个中间对象：它继承QObject、定义了pyqtSignal，被工作线程 emit 之后，Qt 会自动把调用排到接收者所属的线程（也就是主线程）的事件队列里。这比自己写QMetaObject.invokeMethod或者加锁刷新控件省事得多。参数上，pyqtSignal(str)声明了参数类型，emit 时类型不匹配会在控制台打警告而不是静默失败，这点对调试很友好。按钮的启用状态也一并在这里管，停止按钮初始禁用，避免用户在没启动时乱点导致状态机错乱。

3.2 工作线程：为什么不能让 QThread 直接改 UI

新手最容易犯的错是继承QThread然后在run()里直接self.label.setText(...)，程序大概率随机崩或者界面假死。Qt 的规则是控件只能在创建它的线程里操作，跨线程改控件属于未定义行为，崩不崩看运气。

from PyQt5.QtCore import QThread, pyqtSignal class EngineWorker(QThread): def __init__(self, engine, bridge): super().__init__() self.engine = engine self.bridge = bridge self._running = True def stop(self): # 只置标志位，不强杀线程，让它自己走到检查点退出 self._running = False def run(self): self.bridge.state.emit("运行中") while self._running: try: step = self.engine.step() # 一次完整尝试，内部自己控节奏 except Exception as exc: self.bridge.log.emit(f"[FATAL] {exc!r}") break self.bridge.log.emit( f"[{step.ts:.3f}] try#{step.attempt} " f"http={step.status} cost={step.cost_ms}ms msg={step.message}" ) if step.finished: self.bridge.state.emit("已结束") break self.bridge.state.emit("已停止")

这里的要点有三个。第一，stop()只置标志位不做terminate()，因为强制杀线程会让连接池里的 socket 处于半开状态，下次复用直接报错。第二，engine.step()内部必须自带节流，不能让while空转打满 CPU，也不该在 UI 线程里sleep。第三，日志用 emit 发出去而不是直接print，这样界面和终端（如果接了一个 StreamHandler）都能看到同一条记录。参数上，step()返回的对象我习惯用dataclass定义，带attempt、status、cost_ms、finished四个字段，回放日志的时候能直接按 attempt 对齐。

3.3 日志与状态回显：把黑匣子打开

日志我一般做双写：文件里存带毫秒时间戳的原始行，界面上显示裁剪过的短行。文件那份是事后复盘的唯一依据，界面那份是运行时的心理安慰。

import logging from logging.handlers import RotatingFileHandler def build_logger(bridge, path="run.log"): logger = logging.getLogger("practice") logger.setLevel(logging.DEBUG) fh = RotatingFileHandler(path, maxBytes=2 * 1024 * 1024, backupCount=3, encoding="utf-8") fh.setFormatter(logging.Formatter( "%(asctime)s.%(msecs)03d %(levelname)s %(name)s %(message)s", datefmt="%H:%M:%S")) logger.addHandler(fh) class BridgeHandler(logging.Handler): def emit(self, record): bridge.log.emit(self.format(record)) bh = BridgeHandler() bh.setLevel(logging.INFO) # 界面上只显示 INFO 以上，DEBUG 留在文件里 logger.addHandler(bh) return logger

RotatingFileHandler的maxBytes和backupCount是必须给的，抢购类脚本一次跑下来日志能有几十兆，不切分几天就把盘塞满。datefmt里加.%(msecs)03d是关键，毫秒级时间戳是你之后判断「到底是发早了还是发晚了」的唯一证据。界面 handler 设成 INFO 而不是 DEBUG，是因为 DEBUG 里有大量请求头 dump，刷屏之后真正有用的那几行会被顶掉。我一般还会在状态栏加一个「最近一次耗时」的标签，连续几次耗时突然从 80ms 涨到 400ms，基本就是本机网络或者服务端在限流了，比看日志反应快。

4. 纯接口链路与验证码预演：一次下单请求的完整路径

「纯接口」三个字是这个工程的技术核心——不走浏览器自动化，全部靠 HTTP 会话，好处是快、可控、能精确到毫秒，坏处是所有浏览器帮你做的事（保活、签名、验证码、重试）都得自己实现。这一章按请求生命周期往下走：先建会话，再对时间，然后发请求，最后处理验证码。每一步都落一个能跑的片段。

4.1 会话保持与请求签名

会话层的核心诉求是「连接复用」和「重试边界清晰」。连接复用省掉每次请求的 TLS 握手，实测能省 50～150ms，在这个场景里是决定性的；重试边界则关系到会不会重复下单——GET 可以随便重试，POST 绝对不能。

import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry def build_session(cfg) -> requests.Session: s = requests.Session() retry = Retry( total=2, backoff_factor=0.1, status_forcelist=[502, 503, 504], allowed_methods=frozenset(["GET", "HEAD"]), # POST 不进重试名单 raise_on_status=False, ) adapter = HTTPAdapter(max_retries=retry, pool_connections=4, pool_maxsize=4) s.mount("https://", adapter) s.headers.update({ "User-Agent": cfg.user_agent, "Referer": cfg.referer, "Cookie": cfg.cookie, "Content-Type": "application/json", }) return s

allowed_methods只放 GET/HEAD 是血泪经验：一旦把 POST 放进去，遇到 502 网关抖动，urllib3 会在你不知情的情况下重发三次，运气好生成三笔待支付订单，运气不好直接触发风控。pool_maxsize设成 4 就够了，再多也没意义，因为下单请求本身是串行节奏的，只有查询类的接口才需要并发。

签名这一块，不同平台算法不一样，最常见的是「参数按 key 升序拼接 + 盐 + MD5」，也有用 HMAC 的。这里给一个通用骨架，实际盐值只能自己抓包比对：

import hashlib import hmac import random def sign_md5(params: dict, salt: str) -> str: raw = "&".join(f"{k}={params[k]}" for k in sorted(params)) return hashlib.md5((raw + salt).encode("utf-8")).hexdigest() def sign_hmac(params: dict, secret: str) -> str: raw = "&".join(f"{k}={params[k]}" for k in sorted(params)) return hmac.new(secret.encode(), raw.encode(), hashlib.sha256).hexdigest() def build_payload(cfg, ts_ms: int) -> dict: body = { "item_id": cfg.item_id, "sku_id": cfg.sku_id, "num": cfg.buy_num, "ts": ts_ms, "nonce": f"{ts_ms}{random.randint(100000, 999999)}", } body["sign"] = sign_md5(body, cfg.salt) return body

参数说明：ts用毫秒时间戳且必须是对时之后的时间，服务端一般会校验时间窗口，差太多直接拒；nonce是幂等键，同一次尝试里重发要用同一个 nonce，换新的就等于新订单；sign必须在所有业务字段拼好之后再算，多一个字段少一个字段结果全变。调试签名时我一般会把raw字符串也打进 DEBUG 日志，跟抓包结果逐字符比对，差一个&或者参数顺序反了都会导致签名错，这种错最难靠猜解决。

4.2 时间同步：把开抢时刻对齐到毫秒

本地时钟和标准时间的偏差，在有 NTP 同步的机器上通常是几十毫秒，但在一些虚拟机、休眠唤醒过的笔记本上能到几秒。差几秒意味着开抢瞬间你还在等，或者提前太久被判异常。

import time import ntplib class ClockSync: def __init__(self, host="ntp.example.com", samples=5, max_delay=0.15): self.host = host self.samples = samples self.max_delay = max_delay self.offset = 0.0 # 标准时间 - 本地时间，单位秒 def sync(self) -> float: offsets = [] client = ntplib.NTPClient() for _ in range(self.samples): try: resp = client.request(self.host, version=3, timeout=1.0) except Exception: continue # delay 是往返时延，太大的样本说明网络抖动，直接丢 if resp.delay > self.max_delay: continue offsets.append(resp.offset) time.sleep(0.08) if not offsets: raise RuntimeError("对时全部失败，检查网络或换一个时间源") offsets.sort() self.offset = offsets[len(offsets) // 2] # 中位数，抗单次抖动 return self.offset def now(self) -> float: return time.time() + self.offset def wait_until(self, target_ts: float, spin_ms: int = 30): """粗睡 + 细自旋：远的时候 sleep，近的时候空转，兼顾 CPU 与精度""" while True: gap = target_ts - self.now() if gap <= 0: return if gap > spin_ms / 1000: time.sleep(min(gap - spin_ms / 1000, 0.2))

几个参数值得说：max_delay=0.15是过滤样本的门槛，超过 150ms 往返的样本噪声太大，参与中位数反而拖偏；samples=5是因为单次对时结果的方差很大，取中位数比取平均更稳，一次异常样本不会把整体带偏；spin_ms=30是最后 30 毫秒改自旋，再长会烧 CPU，再短又会被time.sleep的最小调度粒度吃掉精度。开抢目标时间这样算：

target = clock.now() + (open_dt.timestamp() - clock.now()) - cfg.advance_ms / 1000

advance_ms补偿的是「从调函数到服务端收到请求」这段链路耗时，包括 TCP 建连、TLS 握手（首次）、序列化、排队。所以更稳的做法是提前几秒先发一个轻量的预热请求把连接建好，让正式那一下走的是复用连接，这段耗时会从 150ms 降到 20ms 以内。

4.3 限频、重试与幂等

限频不是为了省资源，是为了别被当成异常流量。我一般用令牌桶，允许短时突发但长期速率受控：

import threading import time class TokenBucket: def __init__(self, rate: float, burst: int): self.rate = rate # 每秒补多少令牌 self.capacity = burst # 桶容量，也就是允许的突发次数 self.tokens = float(burst) self.lock = threading.Lock() self.last = time.monotonic() def acquire(self, n: int = 1, timeout: float = 1.0) -> bool: deadline = time.monotonic() + timeout while True: with self.lock: now = time.monotonic() self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.rate) self.last = now if self.tokens >= n: self.tokens -= n return True if time.monotonic() > deadline: return False time.sleep(0.005)

rate=1.0、burst=3是我常用的起步值：正常情况下每秒最多一次尝试，允许开头三连发。重试策略要跟幂等键配合——同一次「尝试」内，nonce 不变，超时了可以用同一个 nonce 重发，服务端如果做了幂等就不会生成第二笔；换了 nonce 就是一次新尝试，必须重新走限频。这个区分要在代码里写死，不要靠脑子记。

4.4 验证码预演沙盒：把识别流程做成可回放的一层

预演模块是这个工程最实用的一块。它把验证码「下载 → 预处理 → 识别 → 比对」四步做成离线可跑的流水线，你可以拿历史图片跑一万次看命中率，完全不用碰真实接口。

import cv2 import numpy as np def preprocess(path: str): img = cv2.imread(path, cv2.IMREAD_GRAYSCALE) if img is None: raise FileNotFoundError(path) # 1) 放大：小图直接二值化会把相邻笔画粘成一坨 img = cv2.resize(img, None, fx=2.5, fy=2.5, interpolation=cv2.INTER_CUBIC) # 2) 自适应阈值：比固定阈值更抗背景渐变和局部阴影 img = cv2.adaptiveThreshold(img, 255, cv2.ADAPTIVE_THRESH_MEAN_C, cv2.THRESH_BINARY, blockSize=15, C=8) # 3) 开运算去孤立噪点，核别开大，否则细笔画会被吃掉 img = cv2.morphologyEx(img, cv2.MORPH_OPEN, np.ones((2, 2), np.uint8)) return img

参数上，fx/fy=2.5是经验值，放大到 3 倍以上收益递减但耗时明显上涨；blockSize=15必须是奇数，窗口越大越平滑但越容易把细线抹掉；C=8是从阈值里减去的常数，值越大保留的前景越少，背景噪点多的时候往上调。预演的回放统计我写成这样：

from dataclasses import dataclass, asdict import json @dataclass class ReplayRecord: file: str expect: str got: str cost_ms: int @property def hit(self) -> bool: return self.expect.strip().upper() == self.got.strip().upper() def summarize(records, out="replay_report.json"): total = len(records) hit = sum(1 for r in records if r.hit) by_len = {} for r in records: k = len(r.expect) t, h = by_len.get(k, (0, 0)) by_len[k] = (t + 1, h + int(r.hit)) report = { "total": total, "hit": hit, "acc": round(hit / total, 4) if total else 0, "avg_cost_ms": round(sum(r.cost_ms for r in records) / total, 1) if total else 0, "by_length": {k: {"total": t, "acc": round(h / t, 4)} for k, (t, h) in sorted(by_len.items())}, } with open(out, "w", encoding="utf-8") as f: json.dump({"summary": report, "records": [asdict(r) for r in records]}, f, ensure_ascii=False, indent=2) return report

按长度分组统计是关键：很多验证码是 4 位，但如果混进了 5 位样本，整体准确率会被拉低，看不出真实水平。我一般要求预演集里每类字符至少出现 30 次，否则by_length里的数字没有统计意义。真实运行时的兜底逻辑也要先在预演里演练：识别置信度低于阈值时不硬猜，直接弹窗让人工填，人工填的结果回流进预演集，下次再跑就有新样本了。

5. 避坑与常见问题排查：五个真实翻车现场

这一章全是踩过的坑，按「现象 → 原因 → 解决」写，能对号入座的基本上五分钟内能定位。

5.1 现象：点了「开始」界面白屏，任务管理器里 CPU 跑满

原因几乎一定是有人把循环写在了主线程里，或者在run()里直接操作了控件。Qt 的事件循环被time.sleep或者死循环占住，界面就没机会重绘，看起来像卡死。

解决分两步：先把耗时逻辑全部搬进QThread子类的run()，run()里不许出现任何self.xxx_widget的引用；再检查有没有在run()里调用了QApplication.processEvents()，这个调用在子线程里是无效且危险的，删掉。如果必须从子线程改界面，一律走Bridge的 signal。

提示：调试线程问题时把QT_FATAL_WARNINGS=1打开，跨线程操作控件会直接 abort，比随机崩溃好定位得多。

5.2 现象：昨天还能跑，今天所有请求都返回未登录

原因是 cookie 有有效期，而且往往绑了设备指纹和 IP 段。你从浏览器复制出来的那一串，包含的不只是会话 ID，还有一堆标记位，其中任何一个过期或被服务端判定环境变化，整串就废了。

解决上不要试图自动续期（那属于另一套登录流程，且容易触发风控），做法是启动时先发一个轻量的「检查登录态」请求，失败就在界面上明确提示「cookie 失效，请更新」，而不是让程序带着空会话去跑。配置文件里的 cookie 字段建议改成从环境变量读，os.environ.get("PRACTICE_COOKIE")，避免误提交到仓库。

5.3 现象：对时明明成功了，正式发出去还是比预期晚半拍

原因是你把「本地发出请求的时刻」当成了「服务端收到的时刻」。中间还隔着 DNS 解析、TCP 建连、TLS 握手、请求体序列化，首次请求这一整套下来轻松超过 100ms，而且方差极大。

解决办法是预热：目标时刻前 5～10 秒先发一个成本极低的 GET 把连接建好，让后面的 POST 走 keep-alive 复用。同时把advance_ms从「平均值」改成按「P95 链路耗时」来定，宁可早一点点也不要系统性偏晚。验证方法很简单，在日志里记录「本地发出时间」和「响应里的服务端时间」，把差值画出来看分布，如果 P95 比中位数大出一倍，说明网络抖动大，这时候再压advance_ms意义不大，该换网络环境。

5.4 现象：验证码识别率忽高忽低，同一批图片早上 90% 晚上 60%

原因通常有两个：一是预处理参数是按某一批样本调出来的，字体或干扰线一变就失效；二是图片下载环节有时拿到的其实是一张「请求过于频繁」的错误页，被当成验证码喂给了识别器。

解决上，预演模块里要加一步图片有效性校验——尺寸过小、纯色占比过高、通道数不对的直接标记为异常样本，不进统计。然后定期把线上失败样本回流进预演集重跑，看是不是整体分布变了。参数不要写死在代码里，放配置文件，blockSize和C各留一组备选值，一键切换做 A/B 对比。

5.5 现象：日志里出现多笔待支付订单

这基本是重试策略套在了 POST 上造成的。网关返回 502 时 urllib3 自动重发，服务端第一次其实已经受理成功了，于是变成两笔。另一种情况是你自己在step()里捕获异常后无条件重试，nonce 还每次重新生成。

解决办法有三条同时做：POST 明确排除在自动重试之外；同一次尝试内 nonce 保持固定；发完之后不管返回什么，都先走一次「查询我的订单」来确认真实状态，再决定要不要重试。第三条最费事但最有效，相当于给自己留了一份后悔药。

6. 二次开发：把它从「抢」改成「监控 + 预约」的通用工具

这个工程真正的可复用价值不在下单，而在那套「对时 + 会话 + 限频 + 状态回显」的骨架。我自己改的时候做了两件事：一是把core/order.py里的下单动作抽象成Action接口，二是把整个流程拆成两种模式，用配置切换。

抽象接口大概长这样，Action只约定「做一件事」和「判断是否做完」，具体是下单还是查询由子类决定：

from abc import ABC, abstractmethod class Action(ABC): @abstractmethod def run_once(self, session, ctx) -> dict: """执行一次，返回结构化结果，不许抛异常出去""" @abstractmethod def done(self, result: dict) -> bool: """根据结果判断是否可以停止"""

改造时的验证方法我固定走三步。第一步用本地 mock 服务：起一个 Flask，按需要的状态码和响应体返回，把advance_ms压到 0，跑一百次看有没有重复请求、有没有线程泄漏、停止按钮能不能立刻生效。第二步拿历史抓包回放，把响应体存成 json 文件，用responses库打桩，验证解析逻辑对旧数据仍然兼容。第三步才连真实环境，而且第一次只跑监控模式不跑下单，观察两小时日志确认频率和状态判断都对。

还有个技巧值得单独说：把「一次尝试」的完整上下文（时间戳、请求体、响应体、耗时）序列化成一行 json 落盘，事后写个小脚本按attempt排序重放，能复现绝大多数偶发问题。我一开始嫌麻烦没做，后来为了查一个「偶发 4 次尝试都超时」的问题翻了两天日志，从那以后每次改链路我都会强制走一遍「先打桩跑一百次，再看上下文落盘能不能还原现场」的流程，缺一步不动手。希望这套拆法帮到你。

本文还有配套的精品资源，点击获取