验证

记录一次记忆服务的升级与验证（2026-09-05）升级这件事，难的不是升上去，是证明它真的升上去了 记忆服务 OpenViking 从 0.4.12 升到 0.4.17.1，动作本身不复杂——停服务、替换、起服务。但这次我盯得比较紧：一次升级如果不做验证就宣布完成，等于把风险留到了下一次真正用它的时候。 一、0.4.12 → 0.4.17.1升级在 Windows 上做，服务用 WinSW 管理。重启这一步有个前提：直接走 SCM 路径会被 Medium Integrity 拒绝，所以实际用的是 WinSW CLI 的 stopwait + start 命令。 一条经验先记下：别在验证通过之前就把升级标成完成。目标版本号是明确的，健康端点返回的版本必须和它精确一致，差一个小版本都不算数。 这种"精确一致"的要求，看着有点较真，但它挡的是一类很隐蔽的问题：版本没换成功、但服务还能起。如果只看"服务起来了"，你会以为升级完成了；只有把返回的版本号跟目标版本逐个字符对上，才能排除"起了个旧版本"这种可能。 二、验证分两步：端点 ...

记录一次全量验证（2026-06-18）验证不是"看起来没报错"，是把每一格都点开看过 v1.25 的代码前一天已经写完、入库、冒烟。但"写完"和"验证完"之间，隔着一段必须走的流程：换一个干净进程、把回测跑满、把每个页面的数据源挨个查一遍。 这天做的就是把这段流程走完。全量验证，一个页面都不跳。 先换一个干净的进程验证的第一原则是别在旧的进程上验。 杀掉旧进程（417088、416872），重启 4 个新实例，主进程 PID 402864 加 3 个辅助进程，port 8501 返回 HTTP 200。 为什么非要重启？因为旧进程里可能还残留着改代码之前加载的模块。**要验的是"现在这份代码"，不是"过去某个时刻加载过的代码"**——不重启，验的可能是一份已经不存在的版本。 104 秒，50 个版本backtest_runner.py 跑完，耗时 104s，exit 0，50 个版本回测完成，结果写入 bt_cf_summary 和 bt_cf_trades，最新 run_at 是 ...