=== 1. 为什么去掉「显示条数」选择器 === topk 的 N 不影响查询成本（扫描的 chunk 集合完全相同），实测： topk(10) 17833ms / 11 条 topk(30) 18019ms / 34 条 topk(50) 7394ms / 54 条 topk(100) 17553ms / 74 条 波动来自集群负载，与 N 无关 —— 它只决定最后返回多少序列。 所以"选 30"既不更快也不更慢，本质是个翻页开关； 而选它还要重新等一次十几秒的查询，纯亏。 改为：一次 topk(50)，前端 10 条/页 → 5 页只需 1 次查询。 附带收益：占比的分母从"前 10 合计"变成"前 50 合计"，更接近真实占比。 副标题明确写清"一次取前 50 个应用（占比按这 50 个合计计算）"。 === 2. 零点结算昨天（daily volume）=== 原来只有 30 分钟 ticker 回补，且启动时间不对齐整点 → 昨天最早的一段可能已经超出 Loki 24h 保留期被删， 结算结果系统性偏低，图上却标"完整一天"，属静默错数。 新增 nextMidnightFinalize()：每天 00:01 触发 FinalizeYesterdayVolume() - 昨天定稿 partial=false - 补一次条数（index/stats，一天一次可接受） - 顺带刷新今天 partial=true 的柱子 ticker 仍保留，负责当天数据的 30 分钟刷新。 === 3. 顺带 === - 去掉每日量"其中 N 天平台没有留存记录"的提示文案（按用户要求） - 修 QuickQueryTemplates.tsx 的未使用变量导致 tsc -b 失败 - 工作区里上一轮中断的"排行体积列"改动一并纳入（app-ranking 返回 bytes， TopAppsTable 增加体积列，快照记录 per-app 字节数） Pod = Hub latest = a16978d2f88b
=== 现象 === 仓库里 6 条快照 partial 全是 true（10-27 到 10-30），前端把昨天的柱子 也画成虚线空心，看着像"每天都在采样中"。 === 根因 === 早期实现把两件事都塞进 partial：「今天还没过完」和「起点超出 24h」。 10-27/10-28 的数据现在已经被 retention 删掉、永远不会再被抓一次， 所以这两条错误标记会永久留在库里。 === 修法 === prune 里加幂等修正：过去的天，只有快照是**在那天结束之后**才抓的 （说明抓到的是完整一天）才改成 partial=false；当天中途抓的继续保持 partial （那时确实只有半天，不能伪装成完整数据）。 === 测试（3/3 PASS）=== TestPruneDailyVolumeNormalizesPartialAndDropsExpired · 昨天结束之后抓的 → partial=false · 前天中途抓的 → 保持 partial=true · 今天 → 保持 partial=true · 超留存期 → 被清理 · 条数不被清理流程清空 TestUpsertVolumeSnapshotKeepsEntries 刷新体积不清空已抓到的条数 TestGetDailyVolumeHistoryReturnsAllDaysWithMissing 始终返回 days 个点，缺的标 Missing 不伪造 0 go vet ./services/ ./models/ 干净；go test ./services/ 全绿。
opsx
opsx
opsx
opsx