Skip to main content

​
简短回答

账户时区保持 UTC+0

默认的 London (UTC+0/+1) 就是正确设置，不要改。日志库本身按 UTC 记录，UTC+0 与数据源一致

弹窗选「暂时忽略」

控制台检测到设备时区不同会弹「本地设置建议」，点左边的「暂时忽略」，不要点「切换到 Asia/Shanghai」

导出文件一律 UTC+0

导出和汇总账单两个按钮产出的文件都固定按 UTC+0，不受账户时区影响；页面上看到的时间则跟随账户时区
已经切换过时区的用户，改回 London (UTC+0/+1) 即可。 切换时区只影响页面展示，不会改动、也不会丢失任何已产生的调用数据，也不会改变导出文件的内容——导出始终按 UTC+0。改回来之后，页面显示与导出文件的口径重新一致。
一句话记住：导出来的（导出文件、汇总账单、日志查询 API 的 created_at）都是 UTC+0；在页面上看的（明细列表、统计图）跟随账户所选时区。

​
账户时区在哪里看

在控制台的用户信息一栏可以看到当前账户时区，正常应显示为 London (UTC+0/+1)，也就是 UTC+0。

控制台「用户信息」一栏的时区设置，正常为 London (UTC+0/+1)

​
弹出「本地设置建议」时请选「暂时忽略」

当账户时区（UTC）与你当前设备的时区（例如 Asia/Shanghai）不一致时，控制台会弹出一个「本地设置建议」窗口，并给出「切换到 Asia/Shanghai」的按钮。

控制台弹出的「本地设置建议」窗口，请点左侧的「暂时忽略」

请点「暂时忽略」，不要点「切换到 Asia/Shanghai」。 切换后，日志页顶部的**「调用数据一览」统计图**展示会错位——时间分桶与图表区间对不上，看起来像数据缺失或整体平移。
受影响的就是日志页顶部这一栏：

日志页顶部的「调用数据一览」，账户时区被切换后此处统计图会错位

日志明细列表里的时间同样跟随账户时区显示。但导出文件始终是 UTC+0，不跟随这个设置——所以把账户时区保持在 UTC+0，明细、统计图、导出文件三者口径才一致，换算时统一加一个固定时差即可。

​
两种导出方式怎么选

日志页右上角有导出和汇总账单两个按钮。

日志页右上角的「导出」与「汇总账单」两个按钮

两个按钮的时区口径相同，都是 UTC+0，与账户时区设置无关；差别只在数据粒度和数据量。选哪个只看你要逐笔记录还是要按天的总额。

​
页面上的时间和导出文件对不上，是预期行为

这是对账时最容易踩的坑：页面按账户所选时区显示，导出文件按 UTC+0。 如果账户时区被改成了 UTC+8，一笔发生在北京时间 2026-08-14 00:30 (UTC+8) 的调用：
  • 在页面明细列表里显示为 2026-08-14 00:30，属于 8 月 14 日
  • 在导出文件里是 2026-08-13 16:30（UTC+0），落在 8 月 13 日
于是「凌晨 0–8 点 (UTC+8) 的调用不在当天汇总」——看起来像数据丢了，实际只是两边差了 8 小时。
把账户时区改回 London (UTC+0/+1)，两边口径就一致了，这是最省事的做法。 如果因为其它原因必须保留本地时区，那就以导出文件为准，在自己的表格或脚本里统一换算（见下）。

​
导出 → 后台异步导出（更推荐）

需要逐笔消费日志时，用导出按钮，并在弹窗里选择后台异步导出。

「选择导出方式」弹窗：导出字段可选，导出方式建议选「后台异步导出」

要点：
  • 时区固定 UTC+0，不受账户时区设置影响。因为导出的就是数据库日志本身，需要自己换算成本地时间（UTC+8 用户加 8 小时）
  • 导出字段可选：使用时间、请求 ID、令牌名称、模型名称等，按对账需要勾选
  • 导出方式：数据量大时选后台异步导出，任务在后台跑、不阻塞页面操作，官方建议超过 1 万条记录时使用
  • 导出格式：Excel（.xlsx，超大数据自动拆分并打包 zip）或 CSV（.csv，适合小数据量）
  • 最大导出记录数：填 0 表示不限制（服务端自动拆分多个 Excel 并打包 zip），上限 5000 万条
  • 进度查看：任务创建后在「任务管理」页面查看导出进度与状态，完成后直接下载
完整的导出操作步骤和归档建议见调用日志保存多久？多久清理一次？。

​
对账实务

1

统一换算成北京时间

  • 可读时间：导出文件里的时间加 8 小时就是北京时间。2026-08-14 00:30:00 UTC+0 → 2026-08-14 08:30:00 (UTC+8)
  • Unix 秒（日志查询 API 的 created_at）：数值上加 28800（8 × 3600）
2

要严格按「自然日」分桶时，先换算再分桶

在 Excel 或自家脚本里把所有时间统一加 8 小时，再按 YYYY-MM-DD 分桶。 不要直接拿导出表里的日期列做对账——这是页面与导出文件对不上的最常见原因。
3

报障时同时给出 UTC+0 和 UTC+8 两个时间

客服按 UTC+0 检索日志，给北京时间便于你的业务同事理解。两个时间都写，省去一次来回。
对账、审计这类需要按「业务日」切分的场景，建议优先用日志查询 API 自己跑脚本， 比依赖导出 CSV 更可控——脚本里加 28800 秒比改 Excel 公式靠谱。

​
常见问题

因为后台的调用日志本身就是按 UTC 记录的数据库日志。账户时区保持 UTC+0，页面展示、统计图和导出文件三者口径一致，换算时统一加一个固定时差即可；改成本地时区后，各处的换算规则不再一致，反而更容易看错。
不会。时区只影响页面展示，不会改动任何已产生的调用记录和扣费数据，也不影响导出文件的内容。把账户时区改回 London (UTC+0/+1)，页面显示与导出文件的口径即重新一致。
在导出文件的时间上加 8 小时就是北京时间。例如导出文件里的 2026-08-09 08:00 对应北京时间 2026/8/9 16:00 (UTC+8)。跨天对账时留意这个 8 小时的位移。
因为两者时区口径不同：页面明细列表跟随账户所选时区，导出文件固定 UTC+0。如果账户时区是 UTC+8，凌晨 0–8 点 (UTC+8) 的调用在页面上属于「今天」，在导出文件里落在「昨天」。这是预期行为，不是数据错误。把账户时区改回 UTC+0 即可消除这个差异。
不能。导出固定按 UTC+0，因为导出的就是数据库日志本身。如果你的业务时区不是 UTC+8，也同样需要自行换算。
不能。接口只收发 Unix 秒级时间戳（天然为 UTC），不接收时区参数，客户端按需自行转换。
没有。导出的字段与后台日志展示一致——时间、请求 ID、令牌名称、模型、token 数、金额、状态等，不含任何 prompt 或模型输出内容。详见调用日志保存多久？多久清理一次？。
可以，见日志查询 API。该接口的 start_timestamp / end_timestamp / created_at 都是 Unix 秒级时间戳，与控制台的时区设置无关，程序侧自行按需转换即可，适合自动对账场景。
先在「任务管理」页面确认任务状态。数据量特别大时（例如几百万条）后台拆分和打包需要时间，建议缩小时间范围或设置合理的最大导出记录数，分批导出。

​
相关文档