🌡️ Polymarket 香港天气做市系统 — 完整实现文档

作者: Spark ⚡ | 创建: 2026-04-26 | 基于截至 2026-04-26 16:36 的实际代码

目录

1. [系统总览](#一系统总览)

2. [数据管线](#二数据管线)

3. [预测模型](#三预测模型)

4. [做市引擎](#四做市引擎)

5. [下单系统](#五下单系统)

6. [Web Dashboard](#六web-dashboard)

7. [钱包架构](#七钱包架构)

8. [风控系统](#八风控系统)

9. [部署与调度](#九部署与调度)

10. [附录: 踩坑记录与注意事项](#附录-踩坑记录与注意事项)

一、系统总览

1.1 核心流程

HKO 天文台 API  ──→  hko_data_fetcher.py (每10分钟)  ──→  hko_latest.json
                                                              │
                    ┌─────────────────────────────────────────┘
                    ▼
            hko_predict.py (每10分钟)
            21信号集成 → prob_distribution
                    │
                    ▼
            hko_prediction.json
                    │
    ┌───────────────┼───────────────┐
    ▼                               ▼
weather_mm_runner.py          Web Dashboard
(每5分钟扫描+报价)             /mm/weather
    │                               │
    ▼                               ▼
weather_quotes.py              /weather/hk
非对称报价生成                  预测展示页面
    │
    ▼
CLOB API → Polymarket 挂单

1.2 代码结构

polymarket/
├── scripts/
│   ├── hko_data_fetcher.py      # 🔵 HKO 数据采集 (1037行)
│   ├── hko_predict.py           # 🟢 核心预测模型 (1633行)
│   ├── weather_arb_scanner.py   # 🟡 全城市套利扫描 (2675行)
│   ├── hko_backfill.py          # 历史数据回填
│   ├── hko_backtest.py          # 回测框架
│   └── hko_llm_reasoning.py     # LLM 推理分析
│
├── src/mm/
│   ├── weather_signal.py        # 🔵 预测信号读取 (273行)
│   ├── weather_quotes.py        # 🟢 报价引擎 (445行)
│   ├── weather_mm_runner.py     # 🟢 做市主循环 (1209行)
│   ├── clob_client.py           # 🔵 CLOB API 客户端 (769行)
│   ├── paper_trader.py          # Paper trading
│   ├── quote_engine.py          # 通用报价框架
│   └── signals.py               # 通用信号框架
│
├── src/web/
│   ├── app.py                   # 🟢 Flask 应用 (~10K行)
│   └── templates/
│       ├── mm_weather.html      # MM Dashboard 前端 (~3K行)
│       └── weather_hk.html      # HK 天气预测页面
│
├── data/
│   ├── hko/
│   │   ├── hko_latest.json      # 实时 HKO 数据
│   │   ├── hko_prediction.json  # 最新预测结果
│   │   └── hko_curve_YYYYMMDD.json  # 逐时曲线
│   └── mm/
│       ├── weather_state.json   # MM 运行时状态
│       ├── weather_quotes.jsonl # 报价历史
│       ├── weather_fills.jsonl  # 成交/挂单记录
│       ├── weather_positions.json # 持仓
│       └── auto_trading.json    # 自动交易开关
│
└── docs/
    ├── weather-prediction-mm-strategy.md  # 策略设计文档
    └── weather-mm-system-complete.md      # 📄 本文档

1.3 部署位置

二、数据管线

2.1 数据采集: hko_data_fetcher.py

运行频率: 每 10 分钟 (cron)

采集的数据源:

输出:

2.2 外部数据源 (Open-Meteo)

三、预测模型

3.1 核心算法: hko_predict.py

21 信号加权集成模型 + LLM 推理，运行频率每 10 分钟。

公式:

predicted_max = Σ(signal_i × weight_i) / Σ(weight_i) + bias_correction

3.2 信号分类

📡 实时信号 (10个)

📄 预报信号 (4个)

📊 基准+外部信号 (4个)

📅 气象预报信号 (Open-Meteo, 5个)

📅 相似日信号

🧠 LLM 推理信号

LLM 推理信号使用 DeepSeek V4 Pro 模型，接收完整 HKO 观测 → NWP → 预报 → 历史上下文，输出结构化的温度预测。其优势包括：

3.4 概率分布生成

预测模型输出概率分布的核心逻辑：

# 从 predicted_max 和 uncertainty 生成正态分布
# 按温度 bin 离散化，每个 bin 宽度 1°C
# 应用 hard lower bound (已观测到的最高温)
# 归一化到总和 1.0

关键参数:

3.5 结算规则

- 28.9°C → 结算 28°C (不是四舍五入)

- °C 城市: round((F-32)*5/9) = 整数 °C

- °F 城市: 直接用 °F 整数

3.6 偏差修正

predicted_max += bias_correction  # 默认 +0.7°C (历史回测)
bias_correction = max(0, recent_3day_error_avg × 0.5)  # 自适应

3.7 🚩 午夜峰值锁定覆盖 (Midnight Peak Lock Override)

引入时间: 2026-05-05 | 触发事件: 5月5日HK多云有雨日，午夜最高达23.0°C后气温持续下降至20.2°C

问题: 当日内最高温出现在凌晨/午夜（非正常日间升温），且白天完全没有升温条件时，climatology（近7日均值27.9°C）和diurnal_curve（27.5°C）等历史经验信号严重拉高预测值，完全不符合当日实际天气。

检测条件（在 hko_predict.py 中，LLM 推理信号之后、权重归一化之前执行）:

if (hko_max_midnight >>= current_temp + 0.8°C  # 温度从午夜峰值下降
    AND current_hour < 14                     # 早晨/午前
    AND sunshine_idx < 0.15                   # 无阳光
    AND forecast_wx is cool/rainy/cloudy      # 天气不支持升温
    AND (HKO_forecast ≈ midnight_peak         # 官方预报确认
         OR NWP_all_low)):                     # 或所有模型预测低
    → midnight_peak_locked = True

触发锁定后的权重覆盖:

关键效果:

典型触发场景举例:

四、做市引擎

4.1 信号模块: weather_signal.py

核心函数:

4.2 报价引擎: weather_quotes.py

核心函数: calculate_quote(temp, comp_type, market_mid, market_bid, market_ask, ...)

Edge 阈值: 统一 20%。仅当 |edge| ≥ 20% 时生成强信号报价。

报价模式:

盘口对齐定价 (当前实施):

# 有流动性 (spread < 50%)
if ob_is_liquid:
    if mode == 'buy_biased':
        bid_price = min(best_bid + tick, fair - tick)
        ask_price = best_ask
    elif mode == 'sell_biased':
        ask_price = max(best_ask - tick, fair + tick)
        bid_price = best_bid

# 无流动性 (spread ≥ 50%) → 回退 fair-price 定价
else:
    bid_price = fair - spread/2
    ask_price = fair + spread/2

动态 Spread 调整:

仓位大小:

仓位大小按档位取整: 5 → 10 → 20 → 30 → 40...

价格限制:

4.3 做市主循环: weather_mm_runner.py

运行模式:

扫描流程:

1. 读取最新预测 (hko_prediction.json)
2. 获取当天活跃 HK 天气合约 (Gamma API)
3. 解析合约日期 (parse_market_date)
4. 获取市场价 (Gamma API outcomePrices)
5. 获取 orderbook (CLOB API)
6. 对每个合约计算 edge + 生成报价
7. 风控检查
8. 自动交易门控 (auto_trading + 9:00-15:00)
9. 挂单/更新订单

交易时间窗口: 9:00-15:00 北京时间

4.4 风控: weather_risk.py

五、下单系统

5.1 CLOB 客户端: clob_client.py

纯 REST 实现，无 py-clob-client 依赖。

认证方式:

核心 API:

5.2 EIP-712 订单签名 (v2)

2026-04-29 更新: 已从 v1 迁移到 v2。详见 docs/clob-v2-migration.md。

v2 EIP-712 Order struct (11 字段):

salt, maker, signer, tokenId, makerAmount, takerAmount, side, signatureType, timestamp, metadata, builder

关键参数:

MakerAmount/TakerAmount 计算: 同 v1

5.3 链上授权与余额

CLOB 余额 ≠ 链上 USDC 余额。Polymarket 的余额是独立平台记账。

⚠️ 天气市场使用 neg_risk=true，CLOB 下单时同时检查两个合约的授权。缺任何一个都会报 "not enough balance / allowance"。

六、Web Dashboard

6.1 路由总览

6.2 MM Dashboard API

6.3 Dashboard 功能模块

6.4 CLOB API 代理 (CORS 解决方案)

问题: Polymarket CLOB API (clob.polymarket.com) 不返回 CORS 响应头。浏览器端 fetch() 调用会被静默拦截，导致盘口深度面板空白、下单按钮无响应等问题。

解决方案: 所有浏览器端 CLOB API 调用通过 Flask 后端代理：

浏览器 fetch('/api/mm/weather/clob-book/<token_id>')
  ──→ Flask 后端 @8899
      ──→ https://clob.polymarket.com/book?token_id=...
      ←── JSON data
  ←── JSON response (同源，无 CORS 限制)

代理端点:

错误处理: 代理返回 HTTP 502 而非 200，确保前端 .catch() 正常触发并保留旧数据。

前端覆盖率: mm_weather.html 中所有 CLOB 调用 (6 处) 均已通过代理，0 个直接调用残留。

6.5 价格计算规则 (前端)

// 使用 Gamma 聚合盘口价 + tick 取整
BUY  → ceilTick(Gamma_bestBid + 0.0001)
SELL → floorTick(Gamma_bestAsk - 0.0001)

CLOB Tick 取整:

Tick size 由 CLOB 官方 API 按 token 返回，不是按价格分段：

GET https://clob.polymarket.com/tick-size?token_id=<token_id>
→ {"minimum_tick_size": 0.01}  或  {"minimum_tick_size": 0.001}

📄 详见 [挂单策略文档](order-placement-strategy.md)

6.6 盘口数据源

当前使用纯 CLOB 数据源 (2026-04-26 更新)。此前用 Gamma 聚合盘口，后改为纯 CLOB 以保持数据一致性。

七、钱包架构

7.1 地址关系

关系: 0xAf63... 是 Safe 0xe39C... 的 owner。

7.2 下单模式: POLY_GNOSIS_SAFE (当前)

2026-04-29 更新: 从 EOA 切换到 POLY_GNOSIS_SAFE (sig_type=2)。CLOB 余额在 Safe 名下。

1. from_private_key(PK) → 自动派生 L2 API Key
2. API Key 地址 = Signer 地址 = 0xAf63... ✅
3. create_order(token_id, price, size, side, funder_address=SAFE) → EOA 签名
4. Maker = Safe (0xe39C...) = 出资方
5. Signer = EOA (0xAf63...) = 签名方
6. signature_type = 2 (POLY_GNOSIS_SAFE)

不使用 POLY_PROXY (sig_type=1): CLOB API 不支持。使用 sig_type=2。

7.3 资金流向

Safe (0xe39C...)  ─── USDC 转账 ──→  Signer EOA (0xAf63...)
                                         │
                                  USDC approve → NegRisk + CTF Exchange
                                  MATIC (gas) → QuickSwap
                                         │
                                         └── CLOB 下单

7.4 补充资金

# 从 Safe 转 USDC
cd /tmp/poly-relayer && node transfer-usdc.mjs <amount>

# 换 MATIC (gas)
cd /tmp/poly-relayer && node swap-quicksilver.mjs

7.5 环境变量 (.env)

POLYMARKET_PRIVATE_KEY=0xc90e...    # Signer EOA 私钥
POLYMARKET_WALLET_ADDRESS=0xAf63... # Signer 地址
POLYMARKET_BUILDER_API_KEY=...      # Gamma API 用
POLYMARKET_BUILDER_SECRET=...
POLYMARKET_BUILDER_PASSPHRASE=...
POLYMARKET_BUILDER_CODE=...
POLYMARKET_SAFE_ADDRESS=0xe39C...   # Safe 合约地址

八、风控系统

8.1 仓位限制

8.2 自动交易门控

自动交易需要同时满足:

1. auto_trading.json → enabled: true (Web UI 手动开启)

2. 当前时间在 9:00-15:00 北京时间内

3. Risk manager 未触发止损

8.3 自成交防护

8.4 流动性检测

九、部署与调度

9.1 Cron 任务

9.2 运行环境

附录: 踩坑记录与注意事项

以下记录开发过程中的关键错误和教训，按时间倒序排列。

A.1 概率分布 Bug: sigma 膨胀 + bin 边界效应 (2026-04-26)

现象: 预测 28.8°C (结算 28°C)，但概率分布显示 P(29)=63.6% > P(28)=33.7%。

根因 (三层问题):

1. HISTORICAL_MAE_FLOOR 滥用: 模型 uncertainty=0.18 (HIGH)，但被历史 MAE floor 0.7 膨胀到 sigma=0.42 (2.3倍)。当观测已确认预测时，不应再用历史 MAE 兜底。

2. Bin 边界效应: lower_bound=28.8 时，28°C bin 仅 [28.8, 29.0) 宽 0.2°C，而 29°C bin 宽 1.0°C。sigma=0.42 时 P(29) 已经是 P(28) 的 1.7 倍。

3. 归一化放大: 所有 bin 概率之和仅 ~50% (另一半在 lower_bound 以下被归零)，归一化后 P(29) 从 31.5% 被放大到 63%。

修复 (hko_predict.py L1372):

if lower_bound >= predicted_max - 0.3:
    if temp_decline is not None and temp_decline > 0:
        sigma_effective = max(uncertainty * 0.6, 0.09)
    else:
        sigma_effective = max(uncertainty, 0.10)
    UNIFORM_FLOOR_PCT = max(UNIFORM_FLOOR_PCT * 0.25, 0.0003)

教训:

A.2 盘口定价 vs Fair-Price 定价 (2026-04-26)

现象: 低流动性合约 (bid=1¢, ask=99¢) 按盘口价挂单永远成交不了。

根因: MM 报价直接对齐 CLOB 盘口，但低流动性合约的盘口价毫无意义 (边界值)。

修复: 添加流动性检测:

ob_spread_pct = (market_ask - market_bid) / max(market_mid, 0.01)
ob_is_liquid = (market_bid > 0 and market_ask < 1.0 and ob_spread_pct < 0.50)

Spread > 50% → 回退 fair-price 定价。

教训: 不要假设 orderbook 总是有效。极端流动性差的市场需要用 fair price 而非盘口价。

A.3 合约类型解析: "or below" vs "or lower" (2026-04-26)

现象: 部分合约的 comp_type 解析失败。

根因: Polymarket 问题文本用 "or below" 而非 "or lower":

"Will the highest temperature in Hong Kong be 20°C or below on April 26?"

修复: 添加 'or below' in ql or 'below?' in ql 匹配。

教训: 文本解析要覆盖多种措辞变体，不要假设单一格式。

A.4 链上交易判断: NegRisk 不走标准事件 (2026-04-26)

现象: 无法通过 OrderFilled 事件判断成交。

根因: NegRisk 适配器 (0xC5d5...f80a) 不走标准 OrderFilled 事件。

正确方法: 判断 CTF token 转移 + USDC 流向。

教训: 不同合约架构有不同的事件模式，不能假设标准 ERC-20/721 行为。

A.5 代理钱包地址选择 (2026-04-26)

现象: 用 EOA 地址查询 Polymarket 持仓返回空。

根因: Polymarket 用户可能有多代理钱包，持仓在不同地址。

正确做法:

教训: 查询前先确认正确的代理钱包地址。

A.6 SELL 失败: CTF setApprovalForAll 缺失 (2026-04-26)

现象: BUY 下单成功但 SELL 报 "not enough balance / allowance"。

根因: USDC approve 只覆盖 BUY。SELL 需要 CTF token 的 setApprovalForAll 授权。

需要的全部授权:

1. USDC approve → CLOB Exchange (BUY)

2. USDC approve → NegRisk Adapter (BUY)

3. CTF setApprovalForAll → CLOB Exchange (SELL)

4. CTF setApprovalForAll → NegRisk Adapter (SELL)

教训: 下单前检查所有授权，不要只检查 USDC approve。

A.7 CLOB Tick 取整: 价格被拒绝 (2026-04-25)

现象: 下单报 "breaks minimum tick size rule"。

根因: 不同 token 的 tick size 不同（0.001 vs 0.01），价格未按正确 tick 取整。

解决方案: 使用 CLOB 官方 API 查询每个 token 的 tick size：GET /tick-size?token_id=...，前端和后端均在下单前调用此接口。详见 [挂单策略文档](order-placement-strategy.md)。

修复: 添加 ceilTick() / floorTick() 函数。

教训: 下单前务必验证 tick size，不同价格区间 tick 不同。

A.8 Gamma 盘口 vs CLOB 裸盘口 (2026-04-25)

现象: 页面显示的 Gamma 盘口价与下单用的 CLOB 裸盘口价不一致。

根因: Gamma 聚合盘口 (含 AMM) ≈ 网页显示价，纯 CLOB 对低流动性市场价差极大。

演变:

教训: 理解不同数据源的含义，选择与使用场景匹配的源。

A.9 CLOB 下单 5 大签名差异 (2026-04-23)

现象: Python 下单持续报 "Invalid order payload" / "invalid signature"。

根因: 与 @polymarket/clob-client v5.8.1 的 5 个关键差异:

教训: 逆向工程 API 时，逐字段对比参考实现的签名和 payload，不要假设。

A.10 HMAC 签名 Base64 编码 (2026-04-23)

现象: L2 认证失败。

根因: Base64 URL-safe 编码细节:

教训: Base64 编码有多种变体 (standard/URL-safe/with-without padding)，API 对接时需精确匹配。

A.11 USDC vs USDC.e (2026-04-24)

现象: 换了 USDC 但 Polymarket 不能用。

根因: Polymarket 在 Polygon 上使用 USDC.e (bridged USDC, 0x2791Bca...)，不是原生 USDC (0x3c499c54...)。

修复: 通过 Uniswap V3 兑换原生 USDC → USDC.e。

教训: 不同链/平台可能使用不同的 USDC 版本，转账前确认合约地址。

A.12 数据库锁冲突 (2026-04-16)

现象: Web 应用返回 500 错误，DuckDB 锁冲突。

根因: DuckDB 不支持多进程并发写入 + 每次请求创建新引擎。

修复:

教训:

A.13 结算规则理解错误 (2026-04-14)

现象: 4/13 手动结算用了 Open-Meteo 数据导致多笔交易结果错误。

正确规则:

教训:

A.14 Open-Meteo Rate Limiting (2026-04-13)

现象: 频繁 429 错误。

根因: 7 个重叠调度源，每小时 30+ 次扫描 × 14 城市 = 数百次 API 调用。

修复: 禁用重复 cron，频率 5→30 分钟。

教训:

A.15 POLY_PROXY / Safe 下单演进 (2026-04-24 → 2026-04-29)

v1 阶段 (2026-04-24):

现象: 即使官方 SDK 也返回 invalid signature。

结论: Polymarket CLOB 对 Safe 代理钱包的签名验证有 bug 或未支持。

方案: EOA 模式 (from_private_key, sig_type=0)。

v2 阶段 (2026-04-29):

CLOB v2 迁移后，发现:

1. CLOB 余额独立于链上 USDC — 需通过 polymarket.com 存入

2. Safe (0xe39C...) 在 CLOB 有余额，EOA 没有

3. sig_type=2 (POLY_GNOSIS_SAFE) 可用，sig_type=1 (POLY_PROXY) 仍不可用

4. 用 Safe 作 funder + sig_type=2 成功挂单

当前方案: POLY_GNOSIS_SAFE 模式 (funder_address=Safe, sig_type=2)。

教训:

A.16 polymarket.db 大小问题 (2026-04-13)

现象: polymarket.db 达 22.3GB，备份超时被 SIGKILL。

应对: 考虑从备份中排除或增加超时。

教训:

A.17 通知系统不一致 (2026-04-16)

现象: 脚本输出显示东京交易，通知文件记录伊斯坦布尔交易。

根因: 4 个不同通知文件分散存储，31+ 脚本各自写入。

修复: 统一通知目录 + 通知包装器 + 文件锁。

教训:

A.18 部署位置误解: 阿里云 vs 本机 (2026-04-26)

错误: 文档 (包括本文档初版) 声称预测模型运行在"阿里云服务器"上。

事实: 一切运行在本机 macOS VM 上：

教训: 部署位置要以 cron/进程实际运行位置为准，不能凭印象写。

A.20 CORS 导致前端功能全部静默失败 (2026-05-02)

现象: 盘口深度面板空白、下单按钮无反应、但无任何报错。

根因: Polymarket CLOB API (clob.polymarket.com) 不返回 CORS 响应头。浏览器端 fetch() 到不同源被静默拦截 — 网络面板显示 (blocked) 但 Console 可能无报错。

影响范围: mm_weather.html 中共 6 处直接 CLOB fetch() 调用，包括：

修复: 添加 Flask 后端代理端点 (/api/mm/weather/clob-book/ 和 /api/mm/weather/clob-tick/)，所有前端 CLOB 调用改为同源代理请求。代理返回 HTTP 502 时前端 .catch() 可正常处理。

教训:

A.21 预测分布正午过度自信 (2026-05-02)

现象: 12:00 时预测锁定 26°C 概率 99.7%，而实际信号指向 27-28°C (内陆最高已达 29.8°C)。

根因: hko_predict.py 中"确认预测覆盖"逻辑 (lower_bound >= predicted_max - 0.3) 在正午就触发，将 sigma 收紧到 0.114，导致概率分布极度集中。但正午温度下降可能只是云/天气波动，不是真正的峰值下降。

修复: 添加 late_enough_for_lock 时间门控：

同时修复: uncertainty 收紧逻辑 — 14:00 前即使温度下降也不降低 uncertainty。

修复后: 26°C: 72.5%, 27°C: 23.7%, 28°C: 1.3% (合理分布)

教训:

A.22 已成交挂单未从 UI 清除 (2026-05-02)

现象: CLOB 上已成交的订单仍然显示在 Dashboard 的挂单列表中，显示 (剩0.0)。

根因: 三层问题：

1. Polymarket API /data/orders 返回所有订单 (含 FILLED/CANCELLED) — 无状态过滤

2. _get_open_orders_cached() 原样返回无过滤

3. updateStatusBars() 前端渲染所有订单，不隐藏 unfilled <= 0

修复:

教训:

A.23 深度面板 (5档盘口) 闪烁 — 彻底重构 (2026-05-02)

现象: 点击展开后闪烁、DOM 重建丢失、"加载中"文字跳动。

根因: 折叠/展开状态机复杂，renderStatus → renderQuotes 用 innerHTML 重建所有卡片时销毁深度面板 DOM，save/restore 方案治标不治本。

彻底重构 (晚 18:00):

1. 移除折叠逻辑 — 面板始终显示，无需 .show 类切换

2. 固定高度骨架 — _emptyDepthTables() 生成 5行空表占位 (min-height: 220px)

3. 无加载文字 — 用 .qc-depth-age 显示"刚刚更新"→"5秒前更新"→"1分30秒前更新"

4. 每秒更新年龄 — setInterval(_updateDepthAges, 1000) 全局滚动

5. refreshDepthPanel() — 只替换 .qc-depth-content innerHTML，不改全面板

6. renderQuotes 后统一 refresh — 不再需要 save/restore 面板状态

A.24 最优报价闪烁 — DOM 重建消除 (2026-05-02)

现象: .qc-ob (YES/NO bid/mid/ask) 显示短暂闪烁。

根因: 4 处更新点使用 obEl.innerHTML = html 或 obEl.outerHTML = html，每次都销毁+重建全部子节点，导致布局重排 + 可见闪烁。

修复: 创建 _updateObDisplay(card, bid, ask, noBid, noAsk) 函数：

A.24 设计原则总结

1. 预测模型: 历史 MAE 是预报兜底，不是确认预测兜底

2. 盘口: 低流动性市场不要信任盘口价

3. API: 逆向工程时逐字段对比参考实现

4. 结算: 永远用官方数据源，不要用替代源

5. 数据库: 选型要考虑并发模型，DuckDB 不适合高并发写入

6. 链上: 下单前检查所有授权 (USDC + CTF)

7. 文本解析: 覆盖多种措辞变体，不要假设单一格式

8. 钱包: 查询前确认正确的代理钱包地址

9. Base64: 注意 URL-safe vs standard 编码差异

10. Token: 不同链/平台可能用不同版本的 USDC

11. CORS: 浏览器跨源 API 调用需要服务端代理，静默失败很难排查

12. 预测时间门控: 确认/锁定逻辑需要考虑时间上下文，峰值前不要过早收紧分布

13. 订单状态: 不要相信 API 默认过滤，自己显式过滤 FILLED/CANCELLED

14. DOM 更新: 用 textContent 精准更新文本节点，避免 innerHTML/outerHTML 重建 DOM 导致闪烁

15. UI 状态: 需要实时更新的面板应始终可见，固定尺寸 + 时间戳优于折叠/展开 + 加载文字

A.25 5档盘口高亮自己挂单 + 剩余未成交量显示 (2026-05-05)

现象: 自己的挂单（SELL YES / BUY NO 等）没有在 5 档盘口中突出显示，无法直观区分自己的订单和他人订单。

修复:

1. _renderDepthTables — 新增 openOrders 参数，渲染时检查每行是否为我的挂单，匹配时添加 my-order CSS class（蓝色左边框 + 背景高亮）

2. _getMyOrderInfo — 新增函数，按 (token_id, price, side) 精确匹配（误差 < 0.0005），并返回剩余未成交量

3. _isMyOrder — 改为 delegate 到 _getMyOrderInfo

4. 盘口显示 — 自己的挂单行数量后追加 （剩余N） 标记

5. loadOpenOrders — 数据加载完成后触发 refreshTargetedDepthPanels()，确保高亮和剩余量即时更新

效果:

A.26 5档盘口 NO 侧展示错误的订单 (2026-05-05)

现象: orderbook/23/exact 接口返回的 NO 测盘口数据显示价格最高的卖单和最低的买单，而非最有意义的（最低卖价和最高买价）。

根因: 后端 _fetch_orderbook_inner 和 api_mm_weather_orderbook_single 对 YES/NO 两个 token 都使用 bids_raw[-5:] / asks_raw[-5:]。CLOB API 返回的 bids 是升序（低→高），asks 是降序（高→低）。[-5:] 取最后 5 个：

结论: 逻辑正确。NO 侧的显示效果取决于 CLOB 当前深度。当自己的订单价格不在 top-5 最佳价范围内时，不会出现在盘口中。

优化: 通过 _isMyOrder 高亮和剩余量显示帮助区分是否自己的订单在盘口中。

A.27 CLOB SSL 重试耗尽 Worker 修复 (2026-05-05)

现象: 页面卡死，所有 API 请求需要 15-30 秒才返回，gunicorn worker 全部被占满。

根因: Polymarket CLOB API 的 SSL 握手不稳定（_ssl.c:1129 EOF 和 _ssl.c:1112 握手超时），后端对每次失败做了 3 次重试（含 sleep），导致单个 CLOB 请求可能耗时 15-20 秒。4 个 sync worker 很快全部被堵死。

修复:

1. _fetch_clob_best — CLOB 重试从 3 次减为 2 次，超时从 5s 减为 4s，sleep 从 0.3s→0.2s

2. _fetch_orderbook_inner Gamma 发现 — 重试从 3 次减为 2 次，超时从 10s 减为 8s，移除 sleep

3. api_mm_weather_orderbook_single Gamma 发现 — 同上

教训:

A.28 平仓按钮持仓量不足5时不显示 + 价格不跟随盘口刷新 (2026-05-05)

现象: PM 持仓 1 个 NO token，平仓按钮不显示（因为 noCloseSz < 5 被设为 0）。持仓变化或盘口价格更新后，平仓按钮的量和价格不自动更新。

修复:

1. 移除最小 5 的限制 — yesCloseSz < 5 / noCloseSz < 5 改为 > 0 门槛，持仓大于 0 即可平仓

2. $5 notional cap 截断补全 — 当 cap 截断后剩余数量 < 5 时，一次性平全部持仓

3. 持仓刷新触发卡片重绘 — fetchPolymarketPositions() 完成后调用 refreshActiveCards()，确保按钮价格（来自 orderbook no_best_ask）和数量（来自 totalNoQty）实时更新

4. 定时器串行 — setInterval 内 fetchPolymarketPositions 用 .then() 串行化，数据回来后刷新卡片

效果:

本文档随系统演进持续更新。最后更新: 2026-05-05 11:15 CST