按天导出网关用量，怎样避免跨午夜漏单和重复统计

按天导出网关用量，最隐蔽的错误常出在午夜附近：前一天把 00:00:00 包进去了，后一天又包一次；或者程序用服务器时区分日，表格却按北京时间解释。数据量不大时，几条错误很难从总数看出来。

本文给一份跨午夜导出夹具，包含重复抓取、边界时刻和延迟到达记录。执行 python export-window-demo.py，应得到首日 r1、次日 r2,r3，合并稳定键后仍为三条。它是独立算法演练，不连接 New API，也不假定某个版本提供哪一种导出接口。

用半开窗口明确每一秒归谁

以北京时间自然日为例，10 月 22 日窗口应写成 [10-22 00:00+08:00, 10-23 00:00+08:00)。左边包含，右边不含，因此恰好 10 月 23 日零点属于后一天。转换成 UTC 再比较也可以，但必须同时转换两端，不能把一个带时区值和一个无时区值混用。

记录	发生时间	入库时间	归属
r1	22日23:59:59+08	22日23:59:59+08	22日
r2	23日00:00:00+08	23日00:00:02+08	23日
r3	23日00:00:01+08	23日00:05:00+08	23日，但首轮可能未读到

发生时间决定报表归属，入库时间决定某次提取能看见什么。把这两列合成一个“时间”，就无法解释为什么同一天重跑会多出记录。基础指标定义可参考网关用量统计，此处只处理抽取边界。

稳定记录键不等于业务操作编号

用量明细需要一个能区别每次实际尝试的稳定键。如果同一任务重试两次，业务编号相同，但明细键应不同，否则会把潜在的两笔消耗压成一笔。反过来，同一条记录被分页接口或补拉任务再次返回时，应按同一个明细键覆盖或忽略，而不是新增一行。

附件用字典按 record_id 合并，目的是演示去重语义。真实记录若会在流式结束后更新 usage，就不能简单“第一次见到后永远不更新”；还要处理记录版本或更新时间。删除标记、退款和修正记录也应有对应规则，不能把去重理解为丢弃后到数据。

处理延迟，靠回看而不是永远加大超时

演练第一次提取在零点后三分钟执行，只能看到 r2；第二次在零点后六分钟执行，能看到 r2 和 r3。合并后 r2 只保留一次，r3 被补上。这个例子说明可以为近期窗口安排重读，并对稳定键做幂等写入。

回看长度是业务设置，不是官方统一给定的五分钟。先根据真实数据的到达延迟分布选择范围，给超出范围的迟到记录保留补偿流程。报告应标注“临时统计”或“截至某次提取”，不能把第一次导出的文件当成永久不变的账单。

分页与游标还要检查哪几件事

如果源接口只按时间排序，同一毫秒多条记录可能在翻页时漏掉。需要确认它是否支持稳定的次级排序键或快照游标；不支持时，采用重叠读取并按记录键合并，同时验证完整性。不要自行假设 API 的 page、size、起止时间单位或排序方向，以实际接口文档与返回结果为准。

最终交付保存窗口起止、时区、提取时刻、输入文件摘要、原始行数、唯一键数和金额分组。只有 CSV 行数，没有这些元数据，后续很难解释为什么第二次导出和第一次不同。核对不一致时先查窗口与迟到，再查费率，不必一上来怀疑模型计量。

常见问题

把截止时间写成23:59:59就够吗？ 不够。带小数秒的数据可能落在最后一秒内；半开窗口不需要猜系统时间精度。

按记录键去重会漏掉重试吗？ 只有把业务键误当尝试键才会。先定义记录粒度，再讨论去重。

夏令时地区每天都是24小时吗？ 不是。本文采用固定 +08:00 的演练窗口；其他地区应按指定时区的日历边界换算，不能机械加86400秒。

核对依据

核对日：2026-10-23。Python datetime用于带时区时间的比较；RFC 3339用于时间偏移格式。稳定键、回看和验收清单是本文提出的导出方案，不冒充网关内置行为。