故障排障

这一天的活儿，一半在证明系统没坏，另一半在说它其实坏在看不见的地方——automation 把三次失败吞得干干净净，直到我手动跑了一次 tracker 才见到真报错。 今天从一条刺眼的 17.51% 漂移开始，本来以为账户又出大问题，结果口径一换就是 0.08% 的正常波动。后面大半夜都在跟 OOS tracker 和账户对账较劲，中间还顺手发了一篇知乎文章。写到复盘的时候天都快亮了。 一、17.51% 是假警报，正确口径只有 0.08%凌晨刚开始跑 _verify_reset.py 做只读核验，一上来就看到漂移 17.51%，心里咯噔一下。结果细看才发现这是旧口径的假警报：脚本直接拿 accountValue 跟 current_usdc 比，但 current_usdc 是可用现金，不含锁仓保证金，两个根本不是同一个基准。 换成总值 vs 总值的口径后，sanity 检查就正常了： DB 侧可用现金 751.72 + 在仓保证金 160.34 ≈ 912.06 链上 911.30 残差只有 **0.08%**，完全 OK 这个教训又重复了一遍：对账前先看字段定义，不然白白吓自己 ...

一晚上三条"死因"，长得像同一个症状 有些夜里，你会以为在处理一个 bug，其实是四个。那天从 OOS 停写查起，查到最后发现：一条 3 天的数据空洞、一个设错位置的超时、一笔拖了 4.6 天才被硬止损的仓，还有一行缺了 global 的赋值。它们互不相干，却在同一晚一起发作。 一、停写三天的 OOS先看最表面的：factor_ic_oos.db.oos_ticks 从 08-20 18:08 之后就再没写入了，空了 3 天。 runtime_state 给出了另一半答案：next_run_at=None，last_run_at=1787220565（≈08-20 18:08）——调度器在那之后就没再排下一次运行。automation 配置本身还是 ACTIVE，状态显示正常，那只是假象。 代码侧的根因，是 compute_regime()（L177）里的 fetch_candles 没有任何 try/except： 沙箱/网络异常 → fetch_candles 抛异常 → 冒泡到 main()（无顶层捕获）→ 整个脚本崩溃； Gate1- ...

今天的教训：进程僵死往往不是代码崩了，而是那条 start /MIN cmd /c 启动命令在无桌面的计划任务会话里根本拉不起 python。 早上照例去核 A1 的 OOS 监控，本想确认下样本数够没够，结果顺着 tracker 那个一动不动的 tick，挖出一个交易栈整整静默了 40 小时的大坑。下面按我当天的排查顺序记下来。 一、核 A1：tracker 数字没错，但 tick 冻结暴露异常先找到项目真实路径 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard，DB 都在。oos_ticks 从 08-17 的 5 行涨到了 20 行，说明自动化一直在跑。但 tracker 自报 gate1_n=17，我直接数 factor_ic SHORT closed 却有 29，第一反应是不是 tracker 有 bug。 按铁律「自报字段不可信，须逐笔重算」，我开始独立复算。结果跟 tracker 对不上：我数 OOS（closed≥08-10）是 18 笔 / maxDD 57.2% / p&#x ...

数据库里说开着一笔空单，链上却是多单——那一刻要确认的，是这一条腿到底是不是真的。 08-15 例行对账时，发现 hl_testnet.db 里躺着一条很老的 OPEN 记录。对账这件事平时看起来很枯燥，但它偶尔会拽出一笔"幽灵仓"——数据库以为还开着的仓位，链上其实早就不存在了。 一条 25 天的 SOL 空单最先跳出来的是这一条： hl_testnet.db 有 1 个 OPEN 仓：SOL SHORT @ $77.246，开仓时间 2026-07-22，距今约 25 天。 25 天没动的仓位，本身就不正常。这极可能就是 07-30 那一波"半平仓" 遗留下来的——当时 BTC / ETH / SOL 处理过一轮，通过数据库看，只有 SOL 这一笔没清掉。 DB 和链上，一张一张对判断它是不是幽灵仓，做法只有一个：把数据库里的每一个 OPEN，和链上的实际仓位逐一对照。 DB OPEN（sm_positions） 链上真实 一致？ ETH LONG @1891.3, $80 ETH szi=0. ...

模拟盘最坑的地方，不是它亏了钱，而是它让你以为策略已经能跑了 这天打开 http://0.0.0.0:8501/，主流币模拟交易那条曲线几乎全是红的。接下来的几个小时基本都在同一个循环里转：发现一处数据不对，翻代码，改掉，重启，然后发现下一处不对。 下面按当时踩到的顺序记。 第一次运行就崩maincoin_paper.py 里 scan_signals() 返回的是 dict，但 run_tick() 全程用属性访问：sig.confidence、sig.signal.value。所以第一轮 mc_paper_loop 一起来就崩了。 改成 sig["confidence"]、sig["signal"]，顺手删掉没用的 Signal import。这个 bug 的性质其实很典型——函数签名和调用方之间没有契约，写的时候两边各自都对，合起来就炸。 开仓时间和平仓时间一模一样翻交易记录时发现一件事：每一笔的 opened_at 和 closed_at 是同一秒，大量交易 duration=0s。 根因在 close_position 函数（第 19 ...

网络断了就别反复激活版本，激活不等于启动。 今天这一笔必须记下来，从 14:32 到 20:48，三轮 cron 报的是同一个 BLOCKER，时间越报越久，最后一看，sim_decisions 和 sim_trades 的最后一条 ts 停在 02:52:16，已经 17 小时 56 分钟没动过了。 一、20:48 那轮巡检，差距已经拉到了 17h56m20:48 是今天第四轮 cron。前两轮其实已经报警了：14:32 报 gap 11h40m，17:40 报 14.8h。我本来以为可能是哪次重启没拉起来，结果 20:48 再查，sim_decisions/sim_trades 的 MAX(ts) 还是 2026-06-20 02:52:16，gap 直接干到 17h56m，压根没恢复，还越来越长。 不止这一个：sim_dexscreener_signals 整表 last_ts 停在 6/18 11:43，1h/24h 计数全是 0，已经 stale 2 天 9 小时；bt_cf_summary.run_at 停在 6/18 10:44，有 ...

数据"消失"的时候，先看它是被删了，还是根本没写进去 TVL 看板某天开始是空的。不是加载慢，是图表直接报错，一张干干净净的空白。 这天把这块看板修回来。 一块空的图页面 pages/1_tvl_rank.py 里的 Plotly 柱状图，x 轴取的是 protocol 字段： 1px.bar(x='protocol') 它读到的是一个空列，于是图表报错、数据全丢。 前端报错看着像渲染问题，但真正的疑点应该往后推一步：数据是什么时候没的？是同步进来的数据本来就空，还是本来有、后来被写没了？ 根因：往一个不存在的列里写查下来，问题在写入端，而且比想象中更基础。 tvl_rank 表原本就没有 protocol 列。而 save_tvl_rank 在做 INSERT 的时候，把协议名写进了这个不存在的列——结果数据全丢。 同时，页面又反过来用 px.bar(x='protocol') 去引用这个空列，于是一起报错。 这条链子很典型：写入端写了个不存在的目标，读取端读了个空的结果，两头各自沉默，直到图表上什么都看不见，才被人发现。中 ...

一个数字离谱到没人信的时候，问题多半不在那个数字上 新做的 12 号页跑完之后，v1.16.4 的 BUY 数量是 15254。而同一时间，11 号页里真实成交只有两百多笔。 差了将近两个数量级。这天做的事就是把这个数字修回来。 一张对不上的表：11 页 215，12 页 15254起因很朴素：11 号页显示"买的币很少"，12 号页却显示买了 15254 次。策略筛选出要买的币本来应该非常少，两个页面却给出了完全不同的结论。 这里先要分清两个页面在干什么。11 号页读的是 sim_trades，真实跑出来的成交；12 号页是反事实回测，用历史数据按每个版本的规则重放一遍。回测的意义在于"把历史数据和样本重新过一遍，快速筛出最近真正赚钱的策略，顺带看出优化方向"——它能跑出的笔数本来就该和实盘一个量级，绝不该多出几十倍。 15254 这个数字本身就在喊"我不对"。 根因一：combo 的 max() 被避雷策略钻了空子第一层根因在 engine.py 的 score_combo()。 原来的写法是用 max() 取 4 个子 ...

系统在跑，日志在滚，但一笔交易都没发生 这是做交易系统时最让人心慌的一种故障：**它不是崩了，它是"活着但不动"**。 v1.8 部署上去两个小时，0 BUY、0 SELL。进程在，决策在写，就是不下单。 四层诊断：把"不动"拆开面对这种情况，最容易犯的错是直接去怀疑策略——是不是阈值太高了？是不是信号太差了？然后开始降阈值。 但那天没有先动手改参数，而是先做了一次分层排查。因为"0 BUY"这件事，可能在四个完全不同的地方断掉： 层 卡住的表现 1. 策略层 headless 跑出来的 want 比例过低 2. 风控层 策略想买，但被 _risk_check_buy 拒了 3. 仓位层 想买，有额度，但拿不到仓位 4. 持久化层 链路断了，数据根本没进来 排查结果： 第 1 层——健康。 headless 跑 sol + bsc + base 共 120 个 token，**111 个 want=True，通过率 92.5%**。策略评分没有任何问题。 第 2 层——有问题，但只说明一件事。 那 ...

如果你发现自己在打补丁，先退一步：上游修了吗 那天要解决的毛病很小——小到可以忍，但每次都在提醒你它的存在。 那个一闪而过的黑窗口现象是：每执行一次终端命令，屏幕上就闪一下黑色的 cmd 窗口。 它不影响结果，命令照跑，输出也正常。但一天下来闪几百次，人会烦。更要命的是它给人一种"这东西没做干净"的感觉。 查下来是本地装的 Hermes 0.14.0（v2026.5.16，2026-05-18 发布）的一个已知 bug：Windows 上每次调用终端都会弹一个控制台窗口。 先查上游，再动手改第一反应当然是"把弹窗的地方关掉"——找到 Popen 的调用点，加个 Windows 专用的隐藏标志就行。 但我先多做了一步：去看看上游有没有修。 结果很干脆：这个 bug 在 0.15.0（v2026.5.28）里已经修了，做法是加了一个 windows_hide_flags() 的辅助函数。而当时 PyPI 上最新是 0.15.2（v2026.5.29.2）——本地落后了整整两个补丁版本。 那正确的修法就只有一条： 1pip install --upg ...