额度、限流、余额：三个词混着说，账单必然对不上

「我的额度怎么少了」是这类系统最高频的客服问题，而它的根源往往是产品侧把三个不同概念用同一个词表达。用户说额度，你说的是余额；系统拦他的是限流。

三者的定义要泾渭分明

额度是时间窗口内的总量上限，限流是瞬时速率上限，余额是账户层面的预付余额。三者用同一个 UI 文案表达，用户永远对不上账。

分清楚这三者，用户体验和客服成本都会明显下降。

窗口时区必须写清楚

存储层用 UTC、统计层按 UTC+8 折算、周一为一周起点，这是最不容易出错的组合。「今日用量」的争议有一大半来自时区没说清。

用量统计的时间口径必须写清楚，是 UTC 还是某个业务时区，一周从哪天开始。

Key 级限流保护的是共享资源

站点级限流保护站点，Key 级限流保护「一个出错的脚本不会拖垮所有人」。没有后者，一个写错的 while 循环就能把共享池子的额度全部吃掉。

站点级限流保护的是站点，单 Key 级限流保护的是「一个 Key 不会拖垮所有人」。

如果没有 Key 级限流，一个写错循环的脚本就能把共享池子的额度全部吃掉，其他用户跟着受影响。

未激活的 Key 从第一次调用开始计时

包月 Key 通常约定「首次调用起生效」。如果从下单那天开始算，用户买了不用的那段时间会被白白消耗掉——这是很容易被忽略的资损点。

原 Key 续费的最大价值是「不用换 Key」，因为换 Key 意味着所有依赖它的配置都要改。

到期后续费应该从付款核验成功的时刻重新计时，未激活的 Key 则累加待激活天数。

实操：把调用明细按天和模型聚合出来。

用查询凭证查一次用量，你会发现用户其实只想看这四行字。

import collections, json

# 用量查询接口返回最近 100 条调用明细
detail = fetch_usage_detail()          # 你的查询函数

by_model = collections.Counter()
by_day = collections.Counter()
by_status = collections.Counter()

for row in detail:
    by_model[row["model"]] += row.get("total_tokens", 0)
    by_day[row["created_at"][:10]] += row.get("total_tokens", 0)
    by_status[row["status"]] += 1

print("按模型:", by_model.most_common())
print("按天  :", sorted(by_day.items()))
print("状态  :", by_status)

# 明细只保留最近 100 条，所以这里看的是「近期趋势」，
# 要看整月账目应该以服务端返回的汇总口径为准。

几个容易踩的坑

• 把「今日额度」「并发上限」「账户余额」当成同一个东西。
• 日/周/月窗口用的时区没说清楚，用户看到的数字和自己的记录对不上。
• 没有 Key 级限流，一个跑飞的脚本把共享额度吃完。
• 结算重试没有幂等约束，同一笔用量被记了两次。

小结

先跑通最小请求，再逐项加功能——这是接入任何网关都适用的节奏。

文中的配置和示例都能在 https://aiminis.info/ 直接跑一遍，接入文档在 https://aiminis.info/docs/api-integration。