同一秒有两条调用，网关用量累计表为何一次跳过两行

同一秒出现两条调用时，默认窗口可能把时间相同的记录当作一组，因此第一条累计就已经包含第二条。逐请求报表应明确使用ROWS，并为同秒记录补上稳定次序；按秒汇总则可以保留同值组口径。

定义逐事件累计与同秒批次累计两个合法口径

先问清累计列表达什么：截至这一条事件的累计，还是截至这一秒结束的累计。这两种数字都可能正确，区别来自报表定义。如果只在最终结果补ORDER BY，显示顺序虽然整齐，窗口内部仍可能采用原来的时间同值组。应检查OVER括号里的排序，而不是只看整个SELECT末尾。

用同时间戳样本观察默认RANGE的peer

样本中A租户同秒用量为2和3，下一秒为4；B租户另外使用7。按时间的默认帧让A前两条都显示5，明确时间与ID顺序的ROWS得到2、5、9。ID不是增加用量的字段，而是打破同秒并列的顺序键；分租户窗口则让B独立保持7。

逐行核算时，先按租户分组，再按时间与ID列出事件，最后做前缀和；不能将导出显示顺序当成窗口次序。完整程序同时保存两种累计数组，增加同秒样本以后仍可逐项对照。窗口函数要求实际SQLite至少3.25，输出会记录sqlite_version，Python版本本身不能替代这项核对。

核心表达式（完整建表与输入见附件）：

SELECT tenant,id,
 sum(n) OVER (PARTITION BY tenant ORDER BY t,id
 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running
FROM calls ORDER BY tenant,id;

核对退款负值及迟到事件会使累计变化的边界

累计不是永不下降的序列。退款记为负数后，A的最终总量会从9回到8；迟到事件插到较早时间，也会重算后面的累计。对外导出的快照要说明截止时间和事件版本，否则两次导出不同未必是SQL出错。此例只帮助重建明细报表，不把窗口结果当成扣费锁。

适用范围：只计算合成整数用量；不是生产配额扣费或结算，窗口ROWS不修复重复明细和迟到事件。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

把三份附件放入同一空目录后执行run.py，先对照row_totals与range_totals，不要只比较最后总数，因为两种口径最终都可能得到9。再查看refund_total应为8，确认负向事件确实参与计算。修改样本时可以增加第三条同秒记录，手算后再调整断言；如果只改预期数组而不看窗口SQL，就失去了验证口径的意义。

Python3.8以上及标准库；使用Python自带SQLite。程序不读取现有网关数据库，全部样本写入内存或新建临时目录，执行完自动清理；没有任何模型API调用。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对网关用量SQL窗口ROWS RANGE，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（默认RANGE包含ORDER BY同值peer；按事件逐行累计须明确ROWS帧与确定的事件顺序，PARTITION BY隔离租户。）。

继续阅读：两个网关任务同时累计用量为何少一笔，怎样用数据库原子累加替代先读后写；请求计数器只加整数，为什么increase算出小数且不能拿来结账；网关用量与配额背景。