订阅制服务的用量计量和三通道支付

用量为什么容易错#

原实现把「发生了一次使用」和「账上该记一笔」写在同一条请求路径里。于是会出现：

• 重试一次，用量加两次
• 通道回调晚到，账期已经切到下个月
• 统计用的是缓存里的近似值，对账用的是数据库，两套数永远差一截

我把它拆开：

1. 事件：系统里真实发生的使用，只追加，不改历史
2. 计量：按账期把事件聚合成用量，可重算
3. 账单：计量结果生成应付，和支付通道无关
4. 支付：账单去找通道，通道只认识金额和单号

用量对不上时，重算计量即可，不必去改支付流水。支付对不上时，查通道，不必去改事件表。这是从 Jeepay 那条通道经验里带过来的同一条原则：账本和通道不要写在一个 if 里。

三条通道#

支付宝、PayPal、USDT 的对账语言不一样：一个是商户订单号，一个是 Capture，一个是链上确认。对上层账单只暴露「待支付 / 已支付 / 失败 / 关闭」。

USDT 尤其不能只信一次通知。链上确认数、重复支付、少付，都要当成一等公民，而不是「先入账再人工改」。

部署#

Docker Compose 分环境。计量任务和 Web 进程分开跑，避免请求高峰把账期聚合挤掉。密钥和回调地址按环境隔离，文章里不列。

业务名、域名、节点和商户号不在公开材料里出现。这篇只说明计费为什么要分层。