记录一次 Hyperliquid sm_account 链上-DB 漂移告警复盘（2026-09-13）

数据新鲜不代表没脱钩，drift 3502.97% 说明链上权益和 DB 基线已经差了约 36 倍，先确认是不是预期回撤，再决定重置。

9 月 13 号晚上我又盯上了 craw_app1_wz 项目里的 Hyperliquid smart_money 账户，担心 testnet 重置再把 sm_account 的基线和链上搞脱钩，于是让助手跑了一次只读检查。结果直接触发 ALERT，而且漂移幅度远超阈值，又是一次典型的 reset 脱钩。

一、为什么跑这次检查

这个 sm_account 基线脱钩已经不是第一次出现了。之前 09-05、09-06、09-08、09-11 都出现过类似模式：DB 里的基线没跟着链上权益更新，testnet 一重置，两边就错开一大截。所以当天我特意安排了一次例行防脱钩检查，目的就是看基线有没有再次和链上脱开。

检查脚本是 _sm_sanity_check.py，放在项目目录 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 下面。我让助手必须用 Bash 工具执行，并且打开 dangerouslyDisableSandbox=true，因为脚本要访问 Hyperliquid testnet 的外网接口，普通沙箱环境出不去。

二、执行流程与只读约束

当天跑检查的流程我在指令里写得很死，防止误操作：

  1. 先 cd 到项目目录：cd "C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard"
  2. 用 anaconda 的 Python 运行检查脚本：C:/ProgramData/anaconda3/python.exe -u _sm_sanity_check.py
  3. 脚本会打印一行 [时间] OK chain=... db=... drift=...% 或者 [时间] ALERT ...，退出码 0 表示正常，1 表示漂移超过 5% 阈值。
  4. 如果输出含 ALERT 或退出码为 1，就立刻用简洁消息通知我，附上 chain/db/drift 具体数字，并提示疑似 testnet reset 脱钩、需要重置 sm_account 基线。
  5. 如果输出含 OK，就不用打扰我，只在自动化结果里简短确认。

还有一个硬性约束：不要修改任何文件或数据库，只运行检查并报告。 这次从头到尾都是只读操作，没有动过任何一张表、任何一个字段。

三、告警输出和关键数字

助手执行完脚本后，直接返回了一条红色告警，核心数字如下：

  • 链上真实权益：278.8250
  • DB 基线和：10045.9839（current + open_margin=0.00）
  • **漂移 drift = 3502.97%**（阈值 5.0%，远超）
  • DB 更新时间：2026-09-13T20:41:57，距执行约 7 分钟前，数据新鲜非陈旧

看到这个输出，我第一反应是“数据是不是旧了”，因为以前有过缓存陈旧导致误报的情况。但助手专门确认了 DB 更新时间是 20:41:57，距离执行只过了大约 7 分钟，说明不是陈旧数据，而是真的漂了。

按脚本规则，ALERT 对应退出码 1，也就是漂移已经超过 5% 阈值。这次实际漂移 3502.97%，阈值只有 5%，差得不是一点半点，完全不在一个量级上。

四、脱钩模式与历史对照

助手给出的判定很明确：疑似 testnet reset 再次导致 sm_account 基线与链上脱钩——DB 仍停在 legacy 名义基线 ~10046，而链上真实权益已跌到 ~279（差约 36 倍）。 这和 09-05、09-06、09-08、09-11 的脱钩模式一致。

当时我盯着这两个数字看了一会儿：DB 基线和是 10045.9839，链上真实权益是 278.8250，用 10045.9839 除以 278.8250，恰好就是约 36 倍。这说明 DB 里的基线根本没跟着链上走，还停在上一个 legacy 名义基线附近，而链上真实权益已经因为 testnet reset 掉到了两百多。

这里要特别留意的是“数据新鲜”这个点。以前遇到漂移告警，第一反应可能是“是不是同步延迟了”，但这次 DB 更新时间只比执行早 7 分钟，几乎可以排除同步延迟。也就是说，这个 drift 是真的反映了两边账本已经脱节，不是临时缓存导致。

五、处置建议与待确认点

按照我事前定的规则，告警触发后助手要给处置建议。助手给出的建议是执行基线重置脚本：

1
C:/ProgramData/anaconda3/python.exe -u wb_runs/archive/_reset_sm_account.py --apply

但在执行重置之前，有一个关键决策点必须先确认：当前链上的 ~278.83 到底是不是预期的实盘状态。 如果这 278.83 是真实回撤造成的，那贸然重置基线就会把回撤掩盖掉，等于用 reset 来粉饰亏损；如果它是 testnet 重置造成的非正常归零或缩水，那重置基线才是正确操作。

这个判断不能靠脚本自动做，必须人工确认。所以我当天没有让助手直接执行 --apply，只是记录了重置脚本的路径和参数，等确认清楚链上权益来源后再动手。

六、下一步

当天只完成了只读检查，没有执行任何重置动作，也没改过任何文件和数据库。遗留的事情很明确：

  1. 人工确认 Hyperliquid testnet 链上真实权益 278.8250 是否为预期实盘状态；
  2. 如果确认是 testnet reset 导致的非预期缩水，再执行 _reset_sm_account.py --apply 重置基线；
  3. 重置后重新跑一次 _sm_sanity_check.py，预期回到 OK / drift<5%。

下一次自动化跑这个检查的时候，如果基线已经重置，就应该能看到 OK 输出。但在那之前，这条 ALERT 会一直留着，提醒我 sm_account 的链上-DB 之间还有一笔 3502.97% 的账没平。