记录一次全量验证（2026-06-18）

验证不是"看起来没报错"，是把每一格都点开看过

v1.25 的代码前一天已经写完、入库、冒烟。但"写完"和"验证完"之间，隔着一段必须走的流程：换一个干净进程、把回测跑满、把每个页面的数据源挨个查一遍。

这天做的就是把这段流程走完。全量验证，一个页面都不跳。

先换一个干净的进程

验证的第一原则是别在旧的进程上验。

杀掉旧进程（417088、416872），重启 4 个新实例，主进程 PID 402864 加 3 个辅助进程，port 8501 返回 HTTP 200。

为什么非要重启？因为旧进程里可能还残留着改代码之前加载的模块。**要验的是"现在这份代码"，不是"过去某个时刻加载过的代码"**——不重启，验的可能是一份已经不存在的版本。

backtest_runner.py 跑完，耗时 104s，exit 0，50 个版本回测完成，结果写入 bt_cf_summary 和 bt_cf_trades，最新 run_at 是 2026-06-18 10:44:44。

这一步是整个验证的地基：回测是页面的数据来源。回测没跑完，后面看到的全是旧数——页面照样会渲染，图表照样会画，只是画的是昨天的东西。所以验证的第一步不是点页面，而是先把数据源刷成最新的。

五个页面、六张表，逐条对数：

几个对照关系值得记：

**11 号页的 50 行，正好等于刚才跑完的"50 个版本"**——数据源和展示层对上了，这是最该确认的一条。
13 号页对应三张表（cg_global_market / cg_gainers_losers / cg_top_markets），所以"5 个页面"实际查了 6 张表。页面数和表数不等，是正常的。
cg_news_cache 是 0 行，但这次不慌——因为前一天就知道新闻接口受网络限制会空。同样的一个 0，知道原因和不知道原因，是两种心情。
tvl_rank.protocol 这一列"存在"，是 v1.25 修的点，验证它比单纯数行数更有意义。

1 号页渲染正常：15263 个协议、TVL 图表、protocol 列都在，截图存到 C:\Users\Administrator\.hermes\screenshots\v125-validate-1.png。

用 agent-browser 做功能验证时，主页（/）渲染正常，但子页（/review、/backtest 等）的 Streamlit WebSocket session 是空白的。

第一反应是"坏了"。但核下来，这是 Streamlit 本身的限制，不是代码问题——数据已经通过 MySQL 直查确认全部正常。

这就回到一开始那句：页面渲染不出来，不代表数据不对。 一个验证流程里，如果界面层靠不住，就必须有另一条能独立确认数据的路径。这次那条路径是 MySQL 直查——不依赖被验证的那个介质本身，才不至于循环论证。

sim_loop 状态是"未启动"，这正是本次验证的要求——只验证状态，不启动。

很多人会顺手把它拉起来"看看能不能跑"。但验证阶段的目的是确认，不是改变。不擅自启动一个后台循环，是对线上状态最基本的尊重。

真要启动，也应该是在一个单独的、想清楚后果的时刻——而不是在"顺手验一下"里。

三层。

表面是那份 104 秒、50 个版本的回测——数据链路走通了。

中间是那六个页面、六张表的核对：验证的价值不在于"跑成功了"，而在于你真的打开看过每一格。exit 0 只是说进程没崩，不代表页面上的数字是对的。

最里面一层，是那个"空白但正常"的子页。

它提醒我，一个系统里最危险的不是报错，是静默地显示错误的东西。子页空白，我们查清楚了是 Streamlit 的限制；但如果当时只看到"正常"两个字就收工，把这份信任错用到别的地方，早晚会出事。验证的全部意义，就是把"我觉得应该没问题"换成"我确认它是对的"。