1. 先把需求拆开看：自动加价到底在跟什么赛跑
做竞拍类频道的自动化，第一步永远不是写代码，而是把"人手动出价"这件事拆成一条时间线。我接触过的限时竞拍频道，本质上是一个高频刷新的列表页加上一个出价表单：商品有当前价、最小加价幅度、剩余时间、出价次数限制，用户在倒计时结束前提交一个更高的价格，服务端按"价高者得、同价先到先得"的规则判定。人手动做的动作是：盯倒计时、算价格、点加价、填金额、确认、看回执。这五步在网页上大概要花三到六秒，而在最后十秒里，每一次刷新都可能出现新对手，人的手速和注意力就成了瓶颈。
自动加价脚本要解决的正是这个瓶颈：让程序在规则允许的范围内，替人完成"盯盘 + 算价 + 提交 + 校验"这一套循环，把响应时间从秒级压到百毫秒级，同时用预算上限和加价阶梯把"手滑多打一个零"这种灾难性失误挡在门外。它适合两类人参考：一类是想系统学习网页自动化、状态机设计、时间同步这些通用技能的开发者；另一类是经常在竞拍频道里被人最后一秒截胡、想搞明白"对面到底是怎么做到的"的普通用户。哪怕你最后决定不写脚本，把本文的延迟账和时间窗口那部分看懂，手动出价的成功率也会有肉眼可见的提升。
需要提前把话说在前面：这类脚本属于典型的"平台规则敏感型"工具。任何竞拍频道在用户协议里都会写清楚是否允许自动化提交、请求频率上限是多少、异常行为会怎么处理。我写这个东西的定位始终是技术练习和小范围自用，跑之前一定先去读一遍频道的规则页，把请求间隔放到明显低于限制阈值的水平，遇到验证环节就立刻停下转人工。下面的所有实现，都建立在这个前提上。
1.1 三条时间线：本地时间、服务端时间、页面渲染时间
很多人第一次写这类脚本，会理所当然地认为"我本地电脑显示还剩 3 秒，那就是还剩 3 秒"。实测下来这个假设能把人坑到怀疑人生。一次出价从你按下回车到服务端记录，中间至少穿过三段不同步的时间：本地系统时钟、服务端判定截止的时钟、以及页面倒计时组件自己渲染出来的那个数字。这三者之间任意两个都可能差几百毫秒到几秒。
我做过一组粗糙但足够说明问题的测量：拿同一台机器，连续 50 次请求一个返回服务端时间戳的公开接口，记录往返时延（RTT）并取中位数，同时对比本地时钟。结果是本地时钟比服务端快了 1.8 秒，而这个偏差在两天内还漂移了 0.4 秒。也就是说，如果我按本地倒计时"还剩 1 秒"去提交，实际到达服务端时可能已经超时 0.8 秒；反过来如果本地慢，我会提前提交，价格暴露给对手，被反超的概率大增。
正确的做法是把"截止时刻"统一换算到服务端时间轴上。具体是：多次采样求 RTT 中位数，用"发出请求的本地时间 + RTT/2"近似服务端收到请求的本地时刻，再和服务端返回的时间戳相减，得到一个 offset。之后所有决策都用本地时间 + offset当作"服务端现在几点"。这件事听起来很工程化，但它决定了你后面所有的窗口计算有没有意义。
| 时间源 | 典型误差 | 影响 | 处理方式 |
|---|---|---|---|
| 本地系统时钟 | 几百毫秒到数秒，会漂移 | 截止判断整体偏移 | 用 offset 校正，不直接信本地时间 |
| 服务端时间接口 | 受 RTT 影响，单次采样抖动大 | offset 估不准 | 多次采样取中位数，剔除异常值 |
| 页面倒计时组件 | 渲染延迟 + 自身刷新粒度（常见 1 秒一跳） | 看起来"还剩 1 秒"其实不到 1 秒 | 只作参考，不作判定依据 |
| 提交请求的链路耗时 | 50ms 到 800ms，随网络波动 | 踩线提交容易超时 | 预留安全余量，绝不贴着零点提交 |
还有一个容易被忽略的点：页面倒计时往往是一秒一跳的粗粒度组件，它显示"1"的时候，真实剩余可能是 1.0 秒，也可能是 0.01 秒。你要是指望读这个数字做精确决策，那基本等于闭着眼睛踩点。我的做法是把商品详情里能拿到的"结束时间戳"当成唯一真相，倒计时组件只用来给人看。
1.2 技术选型：纯 requests 还是浏览器自动化
选型这件事我纠结过很久，最后的结论是"看频道的出价接口长什么样"。如果出价是一个干净的 POST 表单，参数固定、没有动态签名、没有风控令牌，那requests加一个会话对象就够了，快、稳、资源占用低，一次出价能压到几十毫秒。但现实中大部分竞拍频道的出价请求都带着一堆动态参数：有的有时效性签名，有的绑定了页面加载时下发的令牌，有的还会校验请求头的顺序和来源。这种情况下硬啃接口，维护成本会高到离谱，一次前端改版就能让你通宵。
所以我更推荐浏览器自动化方案，用 Playwright 这类工具驱动一个真实浏览器上下文：它能天然带上前端生成的所有参数，元素定位失败时还能截图排查，调试体验好太多。代价是慢——一次页面操作动辄 100 到 300 毫秒，启动浏览器也要一两秒。解决办法是"长驻页面 + 最小操作"：浏览器只启动一次，页面挂着不关，出价时只做"点开加价框、填数字、点确认"这三个动作，不做整页刷新，靠页面自身的轮询更新价格。
下面这张表是我自己权衡时用的，可以直接抄：
| 方案 | 单次出价耗时 | 抗改版能力 | 调试难度 | 适用场景 |
|---|---|---|---|---|
| 纯 HTTP 客户端 | 30–120ms | 弱，参数一变就废 | 中，需要抓包分析 | 接口稳定、参数静态的内部练习环境 |
| 浏览器自动化（长驻页面） | 150–400ms | 强，跟随前端渲染 | 低，可截图可回放 | 大多数真实竞拍页面 |
| 浏览器自动化（每次新开页） | 1.5–3s | 强 | 低 | 不推荐，太慢 |
| 移动端协议模拟 | 快 | 极弱，签名复杂 | 极高 | 不建议投入 |
我最终选的是第二行。理由很直白：竞拍场景下你要的是"稳"，不是"最快"。快 200 毫秒但每周修一次签名算法，长期算下来是亏的。而且长驻页面的方案有个额外好处——页面上的价格变动是真实推送的，你不需要自己去轮询接口猜价格，减少了被发现异常频率的可能。
1.3 先把边界画清楚：什么能自动化，什么必须人工
这一节我想写得重一点，因为见过太多人把技术问题做成账号问题。我的原则是三条硬线：
第一，规则没写允许的，就当不允许。用户协议里没有明确说可以自动化提交，那就只在自己的测试环境里跑流程，不连真实竞拍。这不是道德说教，是纯粹的风险收益计算——为了省几十秒，赔进去一个用了多年的账号，账算不过来。
第二，遇到验证环节立刻停。不管出现的是滑块、点选还是别的人机校验，程序一律进入暂停态，把截图和上下文写到日志里，等人来处理。任何试图自动绕过校验的思路我都不碰，也不建议你碰，这条路的技术收益远小于它带来的不确定性。
第三，频率必须明显低于阈值。我的默认配置是：观察轮询 800 毫秒一次，出价动作之间强制 1.5 秒冷却，单场竞拍最多出价 8 次。这些数字都刻意留了很大余量。跑得快不等于跑得久，这条在自动化里是铁律。
把这三条写进代码，比写任何花哨的算法都重要。我甚至建议把它们做成配置文件顶部的常量，每次运行前扫一眼，形成肌肉记忆。
2. 项目骨架：从零搭一个能长期维护的出价器
一个能用的脚本和一个能维护的脚本，差别全在骨架。我第一版是两百行的单文件，所有逻辑糊在一起，结果改一个参数要通读全文，第二次跑就出错。后来重构成"配置、驱动、决策、日志"四层，才真正跑顺。这一章讲骨架怎么搭，重点解释每一层为什么这么切。
2.1 依赖清单与目录结构
依赖我刻意压到最少。核心只有三个：playwright负责浏览器驱动，pyyaml读配置，loguru或者标准库logging做结构化日志。时间同步那块用标准库time和statistics就够，不需要额外装 NTP 客户端。刻意不引入重量级框架，是因为这类脚本生命周期短、改动频繁，依赖越少越好修。
目录结构是这样切的：
auction_bot/ ├── config/ │ ├── default.yaml # 默认参数，进版本库 │ └── local.yaml # 个人参数与会话信息，不进版本库 ├── core/ │ ├── browser.py # 浏览器生命周期与页面句柄管理 │ ├── timesync.py # 服务端时间偏移估算 │ ├── bidder.py # 出价动作封装 │ └── state.py # 状态机 ├── logs/ # 按场次分文件 ├── shots/ # 失败截图 └── run.py # 入口local.yaml单独放、并且加进忽略列表，这一点必须强调。里面会有会话凭据、预算上限这些敏感内容，一旦混进版本库或者被同步到公共位置，麻烦就大了。我的习惯是连logs/和shots/也一并忽略，因为它们包含页面快照，信息量不小。
2.2 配置与凭据管理：别把会话写死在代码里
配置文件我分两层。default.yaml放"逻辑参数"，比如加价阶梯、冷却时间、安全余量、重试次数，这些是可以公开的、跟具体账号无关的东西。local.yaml放"个人参数"，比如预算上限、单场最大出价次数、目标商品的关键词过滤条件。会话凭据（也就是浏览器上下文里的登录态）我连 yaml 都不放，单独走环境变量或者一个独立的、权限收紧的本地文件，程序启动时读一次，用完不落盘。
# core/config.py 节选 import os, yaml from pathlib import Path BASE = Path(__file__).resolve().parent.parent def load_config(): with open(BASE / "config" / "default.yaml", "r", encoding="utf-8") as f: cfg = yaml.safe_load(f) local_path = BASE / "config" / "local.yaml" if local_path.exists(): with open(local_path, "r", encoding="utf-8") as f: local = yaml.safe_load(f) or {} cfg.update(local) # 预算上限必须存在且为正数，缺失直接拒绝启动 budget = cfg.get("budget_limit") if not isinstance(budget, (int, float)) or budget <= 0: raise ValueError("budget_limit 未配置或非法，拒绝启动") cfg["poll_interval"] = max(cfg.get("poll_interval", 0.8), 0.8) cfg["bid_cooldown"] = max(cfg.get("bid_cooldown", 1.5), 1.5) return cfg这段代码里有两个刻意为之的设计。第一个是预算上限的强制校验：配置缺失就抛异常，宁可启动失败，也不能带着"None 当上限"的逻辑上路——Python 里None参与比较会直接报错，但如果哪天有人写成bid <= (limit or 999999)，那就是深渊。第二个是轮询间隔和冷却时间的下限钳制，用max()兜底，防止哪天手快把间隔改成 0.05 秒，跑出一个自己都害怕的请求量。
注意：配置里凡是涉及金额的字段，一律用整数表示最小货币单位的倍数（比如统一乘 100 存成整数），不要用浮点数。竞拍价格用 float 累加，跑几轮之后你会看到 199.99999999999997 这种数字，出价表单填不进去，调试能耗掉半小时。
2.3 状态机设计：观察、决策、出价、回溯
第一版脚本之所以失控，是因为它是一串while True加if，随时可能卡在某个分支里出不来。改成显式状态机之后，逻辑一下子清晰了。我定义了六个状态：
| 状态 | 含义 | 出口条件 |
|---|---|---|
IDLE | 等待目标商品进入视野 | 发现符合过滤条件的商品 |
WATCH | 盯盘，轮询当前价与剩余时间 | 剩余时间进入决策窗口 |
DECIDE | 计算是否值得出价、出多少 | 得出出价金额或放弃 |
BID | 执行出价动作 | 收到明确回执（成功/失败/未知） |
VERIFY | 出价后核对页面价格是否变化 | 价格更新或超时 |
HALT | 暂停，等待人工 | 人工干预后回到WATCH |
关键在VERIFY这个状态。很多人出价完就完事，实际上"点下去"和"成交"之间差着十万八千里：可能按钮没点到、可能表单校验拒绝、可能提交成功但页面没刷新。不做回验，你永远不知道自己是真出价了还是白点了一下。回验的方式很简单——出价前记下当前价p0，出价后轮询页面价格，若变成自己出的价p1且p1 > p0，判定成功；若 3 秒内价格没变，判定失败，回到DECIDE重算，而不是无脑重试。
状态机的另一个价值是把"异常"变成一等公民。每个状态里发生的异常都收敛到HALT或者带退避的重试，不会出现异常把主循环打穿的情况。这一点在后半夜无人值守的时候尤其重要——你睡了，脚本抽风，第二天起来看日志一片空白，那才是最难受的。
3. 核心实现：把每一次加价都做对
骨架搭好之后，真正决定成败的是三个细节：加价金额怎么算、时间窗口怎么卡、页面元素挂掉怎么办。这一章逐个拆。
3.1 出价阶梯：别用"当前价 + 最小幅度"这种朴素策略
新手最容易写的就是next_price = current_price + min_increment，逻辑上没错，但实战里几乎必输。原因有两个：一是每一轮都只加最小幅度，会把自己拖进一场无休止的拉锯战，出价次数很快耗尽；二是在最后时刻，最小幅度往往扛不住对手一次大跳，你加一块，人家加五十，你的次数白费。
我用的是一套分段阶梯，核心思路是"前期小步试探、中期跟随、末期一次性封顶"。假设最小加价幅度是m，剩余时间是t：
| 剩余时间 | 加价策略 | 出价次数预算 | 意图 |
|---|---|---|---|
| > 5 分钟 | 当前价 + m | 最多 2 次 | 试探，确认对手是否活跃 |
| 60s – 5min | 当前价 + 2m，且不超过心理价 80% | 最多 3 次 | 跟随，不主动抬价 |
| 10s – 60s | 当前价 + 3m，且不超过心理价 95% | 最多 2 次 | 抢占位 |
| < 10s | 一次性出到心理价上限 | 1 次 | 封顶，不给对手反超窗口 |
这里有个反直觉的点：末期出到上限，看起来是"多花钱"，实际上是省钱。因为竞价的核心成本不是最终价，而是"你出了很多次价最后还是输了"这种沉没成本。一次性封顶把博弈压缩成一锤子买卖，对手要么认，要么抬到超过你的上限——而超过上限的那部分本来也不该由你承担。
代码上我把它写成一个纯函数，输入当前价、剩余秒数、心理价、已出价次数，输出None（不出价）或者具体金额。纯函数的好处是能单元测试，我把过去几十场的手动记录当成用例喂进去，验证每次的决策是否符合预期。
# core/bidder.py 节选 def decide_bid(current, remaining_sec, ceiling, used_count, min_inc, ladder): """返回 None 表示本轮不出价；返回整数金额表示出价。""" if used_count >= ladder["max_total_bids"]: return None if current is None or current <= 0: return None stage = None for s in ladder["stages"]: if remaining_sec > s["min_remaining"]: stage = s break if stage is None: return None if used_count >= stage["max_bids"]: return None if stage["mode"] == "ceiling": target = ceiling else: target = current + min_inc * stage["steps"] cap = int(ceiling * stage["ceiling_ratio"]) target = min(target, cap) # 金额对齐到最小单位，避免出现小数 target = int(round(target / min_inc)) * min_inc if target <= current or target > ceiling: return None return targetmin_inc在这里既是最小加价幅度，也是金额对齐的网格。为什么一定要对齐？很多竞拍页面的输入框只接受以最小幅度为步长的金额，你填 101.37 会被前端拦下来，或者提交后被服务端修正成 101，导致"我以为我出 101.37，实际出的是 101"的误差。这种误差在最后几秒是致命的。
3.2 时间同步：最后三秒到底该怎么踩
时间同步我单独拎出来讲，因为它是整个项目里最容易做错、做错之后最难发现的部分。我的实现是这样的：
# core/timesync.py 节选 import time, statistics, requests def estimate_offset(url, samples=7): offsets = [] for _ in range(samples): t0 = time.time() try: r = requests.get(url, timeout=2) server_ms = int(r.json()["server_time_ms"]) except Exception: continue t1 = time.time() rtt = t1 - t0 # 用 RTT 的一半近似单程延迟 approx_server_now = t0 + rtt / 2 offsets.append(server_ms / 1000.0 - approx_server_now) time.sleep(0.15) if not offsets: raise RuntimeError("时间同步失败，拒绝启动") offsets.sort() # 去掉最高最低各一个，取中位数 core = offsets[1:-1] if len(offsets) >= 5 else offsets return statistics.median(core)几个细节值得展开。采样七次是为了让中位数有意义，太少容易被单次抖动带偏；去掉最高最低是防网络尖峰；sleep(0.15)是为了不把时间接口打成刷子。最关键的容错是"同步失败直接拒绝启动"——带着错误的 offset 去踩点，比不出价更糟，因为你会长期以为自己踩得很准。
有了 offset，剩余时间的计算就是deadline_ts - (time.time() + offset)。至于"最后三秒"这个说法，我实测下来建议不要真踩三秒，而是踩"服务端剩余 6 到 8 秒"这个区间。原因在 1.1 那张表里写过：提交请求的链路耗时波动很大，你算的是 3 秒，实际到达可能是 2.2 秒也可能是 3.8 秒，一旦越过零点就是彻底无效。留 5 秒以上的余量，损失的是"最后一刻才知道对手出价"的信息优势，换来的是"这一枪一定打得出去"的确定性。在竞拍里，确定性比信息优势值钱。
提示：决策窗口的起点不要写死成固定秒数，而是按你实测的提交链路耗时来定。方法是先在测试环境里连续提交 20 次无意义的出价，记录从"函数调用"到"页面回执"的耗时分布，取 P95 再加 1 秒安全余量。这个数字因人而异，我自己环境里是 4.2 秒，别人的网络可能是 7 秒。
3.3 页面元素定位：怎么让它别在关键时刻掉链子
浏览器自动化最脆弱的地方就是元素定位。前端改个 class 名，你的page.click(".btn-bid-2")就废了。我的做法是三级降级定位，按稳定性从高到低排：
第一级是文本锚点，比如"加价"这个按钮上的文字。文本通常比 class 稳定得多，因为改文案要走产品评审，改 class 只是顺手的事。第二级是结构锚点，比如"包含'当前价'三个字的容器里，第一个可点击的按钮"。第三级才是带特征的选择器，比如带某个固定># core/browser.py 节选 async def click_bid_button(page): candidates = [ page.get_by_role("button", name="加价"), page.get_by_role("button", name="出价"), page.locator("[data-action='bid']"), ] for loc in candidates: try: if await loc.count() > 0 and await loc.first.is_enabled(): await loc.first.click(timeout=1200) return True except Exception: continue return False
这段代码里timeout=1200是刻意的：竞拍场景下宁可快速失败重试，也不要卡在那里等 30 秒默认超时。一次点击卡住，整个决策窗口就废了。
还有一个隐蔽的坑：页面元素"存在"不等于"可用"。出价按钮在冷却期内往往是存在但disabled的，你点上去什么也不发生，程序以为成功了，实际什么都没提交。所以每次点击前必须检查is_enabled()，点击后必须做 3.2 里说的价格回验。这两道防线缺一不可。
3.4 日志与回放：出事之后你得能查
日志这块我吃过亏。第一版只在终端print，结果脚本跑挂了，终端一关，什么都没留下。后来改成结构化写入，按场次分文件，每行一个 JSON，字段固定：
# core/logging_setup.py 节选 import json, time, pathlib class SessionLogger: def __init__(self, session_id): self.path = pathlib.Path("logs") / f"{session_id}.jsonl" self.path.parent.mkdir(exist_ok=True) self.f = open(self.path, "a", encoding="utf-8") def log(self, event, **kw): rec = {"ts": round(time.time(), 3), "event": event} rec.update(kw) self.f.write(json.dumps(rec, ensure_ascii=False) + "\n") self.f.flush() def close(self): self.f.close()必须记的字段有五个：服务端剩余时间、当前价、决策结果、动作耗时、页面回执。有了这五个，事后能把任何一次失败完整重放出来——是决策算错了，还是点击没生效，还是点击生效了但被服务端拒绝，一眼就能分辨。flush()每次写入都刷盘，看起来浪费，但脚本崩溃时这是唯一能保住最后几行日志的手段。
截图策略也要有节流。我的规则是：只在三种情况下截图——进入HALT、点击后 3 秒内价格没变、以及每场竞拍结束时各来一张。无脑每轮截图会把磁盘塞满，而且大部分是无用信息。
4. 跑一遍完整流程：从冷启动到收工
纸上谈完，这一章把整个流程串起来，包括启动前的自检、一次完整竞拍的过程记录、以及参数怎么调。所有内容都可以直接照着复现。
4.1 冷启动自检清单
我现在每次启动前都会过一遍这张表，五分钟的事，能省掉一整晚的返工：
| 检查项 | 判定标准 | 不通过的后果 |
|---|---|---|
| 时间同步 | 连续 3 次 offset 估算，标准差 < 300ms | 踩点全错 |
| 登录态 | 打开目标页能正常显示价格而非登录框 | 全程白跑 |
| 元素定位 | 三级降级定位全部试一遍，至少两级可用 | 关键时刻点不到 |
| 预算配置 | 上限为正整数，且已对齐最小加价幅度 | 出价被前端拒绝 |
| 冷却与间隔 | 不低于默认值 | 请求量异常 |
| 日志可写 | 写入并读回一条测试记录 | 出事无记录 |
| 磁盘余量 | 截图目录剩余空间 > 2GB | 写满后崩溃 |
其中"元素定位三级都试一遍"这一步，我建议做成启动时的预热函数，跑一次真实的无害操作（比如点开加价框再关掉），确认整条交互链通。这比等到最后十秒才发现按钮找不到要好太多。
4.2 一次完整竞拍的现场记录
拿一场模拟环境里的竞拍做记录，商品当前价 120，最小加价 5，心理价 200，最大出价次数 8。时间线如下：
- T-6min：进入
WATCH，当前价 120，无人加价。状态机判定剩余时间 > 5min，策略为试探，但used_count=0且当前价低于心理价 60%，先不出手，继续观察。 - T-4min：价格跳到 135，说明有对手。剩余时间进入 60s–5min 档，
steps=2，算出135 + 10 = 145，但 145 超过心理价的 80%（160）吗？没有。出价 145，耗时 280ms，回验成功，used_count=1。 - T-2min：价格被抬到 155。重算：
155 + 10 = 165，超过 160 的 80% 上限，被cap截断成 160，实际出价 160。回验成功，used_count=2。 - T-45s：价格 175。进入 10s–60s 档，
steps=3，175 + 15 = 190，超过心理价 95%（190）吗？刚好等于。出价 190，used_count=3。 - T-12s：价格被抬到 195。剩余时间进入 < 10s 档，但我的实际配置是 < 8s 才封顶，所以此刻还在上一档。重算
195 + 15 = 210，超过上限，返回None，不出价，等封顶窗口。 - T-7s：进入封顶档，一次出到 200。但 200 小于当前价 195 加上最小幅度 5 等于 200，正好等于，可以出。出价 200，耗时 310ms，回验成功，
used_count=4。 - T-2s：页面价格停在 200。倒计时归零，竞拍结束，判定成交。
整场总共出价 4 次，全部成功，没有一次浪费在无效点击上。对比我最早那版"每次加最小幅度"的写法，同样的场景要出价 12 次以上，而且在 T-30s 之后就会被拖进拉锯，最后大概率输。
值得单独说的一点：T-12s 那一步返回None是正确的行为。当时价格 195，我要出就得 210，超过心理价，不出。很多人在这里会"舍不得"，觉得都跟到这一步了，多出 10 块无所谓。这就是典型的沉没成本陷阱，规则一旦破了，下次就是多出 50、多出 100。把心理价写死在配置里、由代码执行，比自己跟自己讲道理有效得多。
4.3 参数调优：三个数字决定成败
调参这件事没有通用答案，但有明确的调法。
第一个是poll_interval（轮询间隔）。太小，请求量上去了，风险大；太大，价格更新滞后，你看到的是旧价。我的经验值是 800ms 到 1.2s。竞拍频道的价格变动通常不会快到需要 100ms 级别捕捉，800ms 足够你在一秒内看到变化。如果你发现经常"看到新价格时已经被人抬了两轮"，那说明该调的是策略而不是间隔。
第二个是bid_cooldown（出价冷却）。这个纯粹是安全参数，我设 1.5 秒起步。它的作用是防止"决策逻辑出错 → 疯狂出价"这种灾难。哪怕代码里有 bug，1.5 秒的强制冷却也能保证一场竞拍最多出几十次，不至于失控。
第三个是ceiling（心理价）。这个不是技术参数，是心理参数。我的建议是开场前就定死，写进配置，运行中绝不修改。定法很简单：查一下同类商品近期的成交记录，取一个你觉得"超过就不值"的数。注意别定成"我猜别人会出到多少"，那是博弈，不是估值。
调参的顺序也有讲究。先固定冷却和间隔不动，只调策略阶梯，用历史记录回放验证决策是否符合预期；策略稳定了再去动间隔和冷却。反过来调，你会分不清是策略问题还是节奏问题。
5. 常见问题与排查实录
这一章全是踩出来的。
5.1 故障速查表
| 现象 | 最可能的原因 | 排查动作 | 处理 |
|---|---|---|---|
| 价格一直不更新 | 页面停留在旧视图，轮询失效 | 看日志里current是否恒定 | 触发一次轻量刷新，重建页面句柄 |
| 点击按钮无反应 | 按钮disabled或不在视口内 | 截图看按钮状态 | 检查is_enabled()，必要时滚动到可视区 |
| 出价成功但价格没变 | 提交成功、页面未刷新，或价格被别人立刻超 | 对比日志中的p0与回执 | 等 3 秒重查，仍不变则判定失败 |
| 时间窗口算错，提前/延后提交 | offset 漂移或未同步 | 看 offset 的历史值 | 每 30 分钟重算一次 offset |
| 程序中途静默退出 | 未捕获异常打穿了主循环 | 看日志最后一行 | 给每个状态套 try，收敛到HALT |
| 日志写了但没内容 | 缓冲未刷盘 | ls -l看文件大小 | 强制flush() |
| 输入金额被拒 | 未对齐最小加价幅度或含小数 | 打印实际提交值 | 用整数运算 + 网格对齐 |
| 长时间无任何出价 | 决策函数一直返回None | 单测decide_bid的输入输出 | 检查ceiling和used_count是否已耗尽 |
这张表我基本都是按"先看日志、再看截图、最后看代码"的顺序查。绝大多数问题在第一步就能定位，因为日志里那五个字段的设计初衷就是让人不用读代码也能判断问题出在哪个环节。
5.2 我踩过的坑与几条私房经验
坑一：以为浏览器上下文能一劳永逸。长驻页面确实快，但它是会"腐化"的——页面在后台久了，前端定时器被浏览器节流，价格推送延迟到十几秒一次。我第一次遇到这个现象时，盯着日志看了半小时，以为是接口挂了。后来发现只要页面在前台可见，节流就消失。解决办法很简单：把浏览器窗口保持在可见状态（不最小化），或者定期触发一次极小的时间戳更新让页面保持活跃。这个坑常规文档里基本不会写，但它能让你在无人值守时全盘失效。
坑二：用一个微信号式的"重试"毁掉整场。早期我给点击加了retry=3，看起来稳健，实际结果是点一下没反应就点三下，三下都成功提交，出价次数瞬间废掉两次，而且价格被自己抬高了两次。自动化的重试必须有幂等判断——只有确认"上一次没生效"才允许重试，而不是"超时就重试"。修正后的做法是：点击超时后先做价格回验，价格变了就说明生效了，不重试。
坑三：心理价配置成浮点。前面提过，但值得再提一次。199.9这种输入在很多表单里会被四舍五入或直接拒绝，而你可能跑了一个小时才发现自己的封顶价从来没生效过。一律用整数，一律用最小单位。
私房经验一：先手动跑十场，再写脚本。我坚持这个顺序。手动跑的价值不是练手速，是让你知道这个频道的真实节奏——什么时间点会有人抬价、抬多少、抬几次、有没有明显的机器人行为。这些信息决定了你的阶梯参数怎么设。跳过这一步直接写代码，等于闭着眼睛调参。
私房经验二：给脚本加一个"心跳"输出。每 30 秒往日志写一行heartbeat，带上当前状态、剩余时间、当前价。事后看日志，你能一眼看出脚本是在几点几分卡死的，而不是从最后一个业务事件去猜。
私房经验三：把"不出价"当成一个正常结果。新手总觉得脚本跑起来了就必须出价，看到None就想去改逻辑。实际上竞拍里最省钱的操作就是不出价。如果你的日志里 80% 的决策都是None，说明你的上限设得合理，说明策略在克制。反过来，每场都出满 8 次，那大概率是阶梯设得太激进，或者心理价定得太松。
私房经验四：单场结束后立刻归档。把这场的完整日志、截图、最终成交价整理成一个 JSON 存起来。跑够二三十场，你就有了自己的数据集，可以回头算"我的封顶策略平均多花了多少钱""哪些档位的出价其实是浪费"。这件事带来的收益，远大于再优化 100 毫秒的响应速度。
最后分享一个我在实际使用中发现的小规律：绝大多数人输在"最后十秒改主意"，而不是输在技术。手动出价的时候，看着价格往上跳，人会不由自主地把心理价往上抬，抬完之后又后悔。脚本最大的价值，可能不是那 200 毫秒的速度优势，而是它不会改主意——你写进去的那个数字，它会老老实实地执行到底。从这个角度看，先把策略想清楚，再动手写代码，顺序反了的话，再精巧的自动化也只是把你自己的犹豫放大得更有杀伤力。
