套餐续费：为什么必须保留原来的 Key

续费时发一把新 Key 看起来很简单，但它给用户制造了真实成本：所有依赖这把 Key 的配置都要改一遍。保留原 Key 才是用户真正需要的。

原 Key 续费的三条保留规则

今日已用量保留、已兑换的当日额外额度保留、未到期则从原到期时间叠加，已到期则从付款核验成功时开始计时。

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

所以续费时要保留：今日已用量、已兑换的额外额度、以及原到期时间的叠加规则。

未激活的 Key 要累加待激活天数

买了一个月但还没用过，续费不应该让它提前开始消耗。

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

续费时采用下单时的最新套餐

价格和权益以订单创建时的快照为准。套餐在用户付款前改了，订单快照也要跟着更新到最新套餐，但要明确展示出来。

一个常见的坑是：运营调整了套餐价格，结果已经创建但未支付的订单也跟着变了。

正确做法是下单那一刻把套餐内容（价格、每日额度、并发数、有效期）快照进订单。

续费入口不应该要求完整 Key 之外的东西

续费只需要完整的 sk-gw- Key。查询用的 10 位凭证不行——它没有续费权限。

任何客户端接入，先把这三样固定下来：Base URL、模型 ID、Key。

模型 ID 不要从文档里抄，要用你的 Key 实际查一次 /v1/models 拿到真实可用的那个。

实操：用查询凭证查用量，不必把完整 Key 交给前端。

查询凭证能查用量但不能续费，这个权限差异是刻意的。

# 查询凭证是一段 10 位字符串，权限远低于完整 API Key。
curl "https://aiminis.info/api/v1/query-key/quota?key=QRY1234567"

# 返回里包含：今日剩余额度、每日额度、有效期、状态，
# 以及最近 100 条调用明细（默认每页 10 条）。
# 浏览器端还会把最近用过的查询凭证存在 Cookie 里，方便下次直接看。

几个容易踩的坑

• 价格用浮点数存储，累加后账目对不上。
• 套餐改了之后已创建的订单也跟着变，用户看到的和付的不一样。
• 续费时没保留今日已用量，等于凭空多给了一份额度。
• 奖励金被撤销但已经被抵扣，产生了资损。

小结

技术上的事大多不复杂，难的是把每个异常分支都想清楚。把这份清单存下来，下次排障会快不少。

文中的示例接口都可以在 https://aiminis.info/ 上直接验证，用量与额度在用户中心 https://aiminis.info/console 随时可查。