From f6992b2387480d5e38f210fcbe57226479dccf50 Mon Sep 17 00:00:00 2001 From: zlt Date: Thu, 10 Sep 2026 09:41:21 +0800 Subject: [PATCH] =?UTF-8?q?=E5=8F=B0=E8=B4=A6=20057=EF=BC=9A=E6=8E=A5?= =?UTF-8?q?=E5=8F=A3=E6=94=B9=E8=AF=BB=E5=BF=AB=E7=85=A7=E3=80=81=E6=96=B0?= =?UTF-8?q?=E9=B2=9C=E5=BA=A6=E5=AE=88=E5=8D=AB=E3=80=81=E4=BB=A5=E5=8F=8A?= =?UTF-8?q?=E9=82=A3=E5=A4=84=E8=AE=A9=E8=AE=A1=E5=88=92=E4=B8=8D=E5=8F=AF?= =?UTF-8?q?=E5=A4=8D=E7=8E=B0=E7=9A=84=E7=BC=BA=E9=99=B7?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 --- docs/复盘决定台账.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/复盘决定台账.md b/docs/复盘决定台账.md index ca403c7..cf32e4e 100644 --- a/docs/复盘决定台账.md +++ b/docs/复盘决定台账.md @@ -527,3 +527,21 @@ - **预期。** 交易日内计划接口不再出现超时；每天只在盘前预热那一次花三十多秒。 - **复核日期。** 连续三个交易日观察 PMS 页面有没有再报超时。 + +## 057 · 2026-09-10 · 计划接口改读当日全量快照；并修掉一处让计划不可复现的缺陷 + +这一条起于你的一句质疑：靠缓存掩盖三十三秒的装配，这个设计是对的么。答案是不对，缓存只是把「每次都三十三秒」变成「每天第一次三十三秒」。查下去还牵出一个更要紧的问题。 + +- **改动一：接口优先读当日全量快照，按请求参数截取。** 出计划时本来就落了一份全量快照（不裁剪、不设主题限额），注释里写明它是「复盘与对账的唯一底本」，只是接口一直没读它，每次请求都现场装配整池。现在接口先读那份底本，读不到或太旧就自动回落到实时装配。实测读快照零点四一秒、现场装配三十二点三秒，快七十八倍。 + +- **改动二：新鲜度守卫。** 快照是出计划那一刻的定格，太旧就不能当今天的计划下发。两条判据，任一不满足就退回实时装配：代码版本要与当前一致（版本变了说明判决逻辑可能变了）；生成时刻距今不超过十六小时。**时间判据用的是「距今多久」而不是「晚于今天几点」**——选股系统容器跑在世界协调时上，早上七点十分出的计划，快照里记的是前一天二十三点十分，拿本地日期算界会差八小时，把新鲜的快照判成过期。显式指定日期时守卫不生效，复盘要拿的就是历史那一份。 + +- **改动三，也是今天最值钱的一条：取因果论断的查询补上确定排序。** 那条查询原来没有 ORDER BY，而它的文档串写着「每票取最近披露日的最多三条」，代码却按数据库返回的天然顺序截前几条。没有排序时那个顺序不保证，于是同一个数据日、同一份代码，**相隔三十二秒的两次装配结果就不一样**：候选卡差五处、逻辑线差五处、候选卡名次差二十处，顶层的候选单与关注名单也不同。计划因此不可复现，下游也不知道自己拿的是哪一份，复盘更无从谈起。补上「按票、披露日倒序、论断编号」三级排序后，两次现算完全一致。 + +- **这条缺陷是怎么被发现的。** 本来只是想验证「快照读出来的与现算的一不一样」，发现有实质差异；排除了代码改动的可能（这两天只动了接口与新增函数，没碰候选卡逻辑）之后，改用「连着现算两次」做对照，才发现现算自己跟自己都对不上。**如果不做这一步对照，会误判成「快照过时」，然后去修一个不存在的问题。** + +- **验证读数。** 两次现算逐行逐字段完全一致；快照截取与真实快照里当时下发的那份逐行比对，代码序列一致、除名次外逐字段一致、名次重编后完全一样；选股系统十个测试文件全部通过。 + +- **预期。** 下次出计划（次日早七点十分）之后，接口走快照路径、毫秒级返回；计划成为可复现的，同一数据日同一代码算多少次都一样。 + +- **复核日期。** 明日出计划后，看接口日志里的 source 字段是不是 snapshot，以及连续两次现算是否仍然一致。