mirror of
https://github.com/Wei-Shaw/sub2api.git
synced 2026-10-07 14:08:14 +08:00
li
e2652eb853
同一笔 ActualCost 会被分别写入两条方向相反的 SQL：
balance = balance - $1 -- 存剩余额度，舍入的是"减法结果"
quota_used = quota_used + $1 -- 存累计用量，舍入的是"加法结果"
两列都是 NUMERIC(20,8)，PostgreSQL 按 half-away-from-zero 舍入运算结果。
金额在第 9 位落到 half 边界时，两侧朝相反方向舍入：
10 输入 token × 0.00000125 + 5 输出 token × 0.00001000 = 0.0000625
× 1.25（分组倍率） = 0.000078125
balance: 10000 - 0.000078125 = 9999.999921875 → 9999.99992188 delta 0.00007812
quota_used: 0 + 0.000078125 = 0.000078125 → 0.00007813 delta 0.00007813
余额少扣、API Key 配额多记，单次相差 1e-8 且随请求量线性累积（1000 次 ≈ 1e-5 USD），
余额、Key 配额与用量记录无法精确对账，只能靠 epsilon 比较勉强吻合。
修复：在参数进入 SQL 之前，把命令中的全部金额统一量化到 8 位小数
（half-away-from-zero，与 PostgreSQL NUMERIC 一致）。两条语句拿到的是
同一个已落在 8 位刻度上的金额，存储阶段不再发生舍入，delta 精确相等。
- 走 shopspring/decimal 而非 math.Round(v*1e8)/1e8：后者在乘除中引入额外
二进制误差，边界值可能被推到错误的一侧
- 量化排在指纹计算之后：指纹是请求幂等键，保持由原始金额派生，
避免升级前后同一 request_id 的重试算出不同指纹而被判为 fingerprint conflict
Fixes #5229