用明确日界线修正“今日”指标

一个运营页面把两项顶部异常数标成“今日”。只读查询按本地当天筛选后，得到的记录数明显更少。排查期间业务持续流转，数量自然会变化，但每轮比较都稳定出现一批属于昨日的记录。

源码中的日期范围解释了差异：下界是昨日零点，上界是今日最后一秒。查询返回的异常记录都真实存在，区间却覆盖了两个自然日。页面标签与实现分别给出了不同的指标定义。

修复为“今日”建立唯一且明确的契约。两项顶部查询都基于同一个请求时刻和指定业务时区生成边界，再用相同条件下的完整明细及业务主键去重数进行验证。

修改查询前先证明日期区间

排查对齐了四类证据：

• 页面上的指标名称和刷新行为；
• 服务传入两项顶部查询的参数；
• 线上数据库语句缓存记录的时间范围；
• 原日期范围与仅今日范围的只读计数。

原查询的开始时间提前了一天。在同一个只读事务中固定观察时刻，再分别运行两种查询，差额全部来自业务时间属于上一自然日的记录。

固定时刻对比十分必要。运营看板持续接收新数据，几分钟前的截图与当前数量不同很正常。验收不能依赖复现某个历史数字，需要证明哪些记录属于指标，并在同一观察点核对顶部数量与这些记录是否一致。

数据库语句缓存提供了独立证据：线上汇总语句收到的参数确实是昨日零点和今日结束时间，与源码诊断一致。由此可以排除重复行、浏览器旧状态或请求失败等其他方向。

把“今日”写成可执行契约

更清晰的通用模型是在业务时区内使用左闭右开区间：

请求时刻 = 时钟当前值
当天开始 = 按业务时区取请求日期零点
次日开始 = 当天开始加一个本地自然日

当天开始 <= 业务时间 < 次日开始

这种边界让午夜只属于一个日期，也无需猜测字段支持的最大小数秒。相邻两天还能直接拼接，前一天的结束位置就是后一天的开始位置。

本次遗留查询使用 Oracle DATE 和闭区间比较，存储精度为整秒。因此实现把同一个自然日契约转换成 00:00:00 至 23:59:59，回归测试同时确认次日零点被排除。若以后改用更高精度的时间戳，应直接使用次日零点的开区间上界；继续使用 23:59:59 会留下小数秒缺口。

两个边界还必须来自同一次时钟读取。分别取开始和结束时刻时，请求若刚好跨过午夜，就可能得到来自两个日期的边界。时区也要显式指定；依赖服务器默认时区会让机器设置参与指标定义。

让顶部参数与列表筛选解耦

页面明细支持日期、单号、节点和分页等条件。顶部指标的产品定义是：在选定组织和项目内统计今日异常，不跟随普通列表控件缩小范围。

修复为顶部查询建立了专用参数集合。它保留组织、项目和异常状态，使用明确的今日边界，并阻止列表中的日期、标识、节点及分页条件进入指标计算。入库与出库查询共用同一组日期边界。

参数契约因此可以直接审查：

参数类型	顶部指标处理方式
业务时区与请求时刻	定义本地当天
组织与项目范围	保留
异常规则	保留
列表日期、单号、节点与分页	排除

异常判定规则没有变化。任一受监控环节曾经超时，该业务单就在当日候选范围内计为异常；最新环节当前正常，也不会抹去历史超时。日期修复只调整哪些业务单属于今日候选，不改变候选单的异常判定方式。

用完整明细对账顶部数量

修复后的日期范围分别进入两条顶部查询。每条查询都核对三项结果：

1. 汇总返回的顶部数量；
2. 相同规则下完整明细的行数；
3. 明细中业务主键的去重数。

只读快照中，三项结果逐类一致。额外样本还确认：同一业务单存在多个超时环节时只计一次；较早环节已经超时、最新环节仍在目标内时，异常仍然保留。这样既证明了日期修复，也保护了原有业务规则。

随后使用遗留项目要求的运行时完成应用构建。临时回归测试覆盖今日零点、今日最后一秒、前后相邻零点、跨月跨年、闰日、多种 JVM 默认时区、输入值不被修改，以及真实服务到查询参数的映射。验证结束后移除了临时测试依赖和源码，最终差异只保留业务修复。

适用边界与可复用结论

本次验证覆盖源码、日期边界、构建和生产只读对账，没有声称修复已经部署。经过评审的代码进入生产后，还需要再次核对线上顶部数量与同口径明细。

实时数量只有同时记录查询、范围、规则版本和观察时刻，才能成为可复核证据。一次快照中的具体数值不应写成固定验收目标。

可复用的方法是把面向读者的时间词转换成可执行区间：只读取一次时钟，明确业务时区，隔离指标参数，使用与存储精度相容的边界，并让每个顶部数量都与它所概括的完整数据集完成对账。