计费系统不能靠「看起来对」，只能靠可重放的检查。
一、一次没有花钱的演练
季度结束那周，他没有上新功能，把沙箱的系统时钟拨到 2028-02-29，重跑一笔 1 月 31 日开始的订阅升级。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
结果出来两个问题。第一，按比例计费的分母取了 31 天（起始月 1 月的自然月长度），而实际周期是从 1 月 31 日到 3 月 1 日的 30 天；按升级时剩余 17 天、价差 8 美元算，每笔少收 8 × 17 ÷ 30 − 8 × 17 ÷ 31 = 4.53 − 4.39 = 0.146 美元。第二，一笔跨月降级的退款行没有指回原账单，对账时只能靠备注认领。
这两个问题都不大，却都足以在真实账单里活过一年。前 14 个月的三次事故合计差错 810 美元：多收 420、少收 270、重复退款 120；它们没有一次是被「看」出来的，都是客户找上门才发现的。
接下来两周他只做这一件事：不改功能，只跑检查。第三周把两个修复合并，第四周重跑同样的三个场景，差异归零。
验收要能重放，不能只看界面。 把一笔一年前的账单重新算一遍、差异为零，比点开十张发票截图更有说服力。
演练要挑最难的那天。 闰年 2 月 29 日、跨月、跨时区，这三类边界能把分母、取整与生效时点的问题一次暴露。
三次事故全在月底。 每月 105 笔账单、420 个 webhook 事件都压在最后三天；这不是巧合，是批量任务最多、人最疲惫的时候。
二、十二项检查
十二项分四维，每项只有「过」与「不过」，不设「基本可用」。
| 维度 | 序号 | 检查项 | 判定标准 |
|---|---|---|---|
| 正确性 | 1 | 状态迁移守卫 | 25 格状态空间中 16 格被显式拒绝 |
| 正确性 | 2 | 金额用整数分 | 全链路无浮点，存储与计算都以分为单位 |
| 正确性 | 3 | 按比例用例 | 30 个用例覆盖跨月、闰年、时区 |
| 可恢复性 | 4 | 写操作幂等键 | 键为 subscription_id + period_start + event_type |
| 可恢复性 | 5 | webhook 验签与重放 | 验签开启，24 小时内可重放 |
| 可恢复性 | 6 | 一年前账单可重算 | 抽一个月重放，差异为 0 |
| 可审计 | 7 | 变更账本 | 每笔状态与金额变更一条不可变记录 |
| 可审计 | 8 | 退款可追溯 | 每笔退款指向原账单，发票号连续不跳号 |
| 可审计 | 9 | 对账三表清零 | 笔数、金额、状态每月差异清零并留档 |
| 可运维 | 10 | 重试有边界 | 最多 4 次，第 1/3/5/7 天，宽限 7 天 |
| 可运维 | 11 | 二次确认 | 退款与改价需二次确认并记录操作人 |
| 可运维 | 12 | 沙箱可演练 | 三个场景每季度各跑一次 |
正确性看的是「拒绝」而不是「通过」。 9 条合法迁移能跑通只是及格；16 格非法空间被挡住，才说明守卫真的存在。
可恢复性看的是重放结果。 每月 420 个 webhook 事件里有 1.5% 会丢失或重投，约 6.3 个；没有补拉与重放，这 6.3 个就会变成漏记。
可审计看的是能不能倒推。 从一笔退款出发，要能走到原账单、原支付、原订阅；中间断一环，审计就只能靠人回忆。
可运维最容易被跳过。 它不产生新功能，检查起来又麻烦；3.0 分的现状不是不会做，是沙箱三场景只跑过一个，退款与改价也一直是单人操作。
三、四维评分与季度排期
四个维度权重不同，加权后得到一个可以比较的总分。
| 维度 | 权重 | 现状得分 | 加权分 | 修后得分 | 修后加权 |
|---|---|---|---|---|---|
| 正确性 | 0.35 | 4.0 | 1.40 | 4.5 | 1.575 |
| 可恢复性 | 0.25 | 3.5 | 0.875 | 3.5 | 0.875 |
| 可审计 | 0.20 | 4.5 | 0.90 | 4.5 | 0.90 |
| 可运维 | 0.20 | 3.0 | 0.60 | 4.0 | 0.80 |
| 合计 | 1.00 | — | 3.775 | — | 4.15 |
权重不是平均分。 正确性占 0.35，因为一次多收 420 美元就能让 7 个团队客户同时质疑账单；可审计占 0.20，出问题时它救命，平时它不产生收入。
先修正确性，再修可运维。 正确性从 4.0 到 4.5 只需要补 30 个用例；可运维从 3.0 到 4.0 需要二次确认与演练，工时更多，但两项一起修能把总分从 3.775 推到 4.15。
分数要每季度重跑。 单次 3.775 说明不了什么，连续四个季度的曲线才有意义；如果一直不动，要么检查太松，要么根本没在改。
季度预算要写死。 13 周 × 3 小时 = 39 小时可用；五项工作共 26 小时，占 66.7%，剩下 13 小时留给事故与临时需求。
| 事项 | 工时 | 排期 |
|---|---|---|
| 补 30 个按比例用例（含闰年、时区） | 8 | 第 2 周 |
| 重放一年前的一个月账单 | 6 | 第 4 周 |
| 沙箱演练失败扣款重试 | 4 | 第 7 周 |
| 沙箱演练部分退款 | 3 | 第 9 周 |
| 沙箱演练降级跨月 | 5 | 第 12 周 |
| 合计 | 26 / 39 | 66.7% |
四、三个沙箱场景
沙箱不是「点一下能付款」，是能把三个最容易出错的路径完整跑完。
场景一：失败扣款重试。 用测试时钟造一笔余额不足，确认第 1/3/5/7 天各重试一次，宽限 7 天内服务不停，第 7 天仍失败才停用；5.0 笔/月的失败里，55% 应被收回。
场景二：部分退款。 剩余 12 天、单价 15 美元，退 6.00；确认退款单、贷记单与 payments 表三处金额一致，且退款行挂回原账单。
场景三：降级跨月。 月初降级、期末生效，当期收款为 0；确认下期账单按新价出，且不产生一笔隐藏的按比例抵扣。
沙箱数据要和生产同构。 至少复制一个真实客户的订阅结构：一个年付、一个团队档、一个 past_due；结构与生产不同，演练就只能证明沙箱能跑。
演练要留记录。 每个场景记日期、耗时、发现的问题与修复提交；没有问题也要记，那说明这个场景已经被覆盖。
发现的问题要回到检查表。 分母取错就补一条用例，退款不挂原单就加一条对账断言；演练的价值在于把发现变成检查项。
复算：
0.35×4.0 + 0.25×3.5 + 0.20×4.5 + 0.20×3.0 = 1.40 + 0.875 + 0.90 + 0.60 = 3.775 ≈ 3.78
修两项后 0.35×4.5 + 0.25×3.5 + 0.20×4.5 + 0.20×4.0 = 1.575 + 0.875 + 0.90 + 0.80 = 4.15
季度预算 26 ÷ 39 = 66.7%
五、行动清单与复算验收
验收不是一次性的，是按季度重复的动作。
- 把十二项检查写成一张表，每项只填「过 / 不过」。
- 用 25 格状态空间跑一遍迁移测试，确认 16 格被拒绝。
- 检查金额字段类型，确认全链路是整数分。
- 补 30 个按比例用例，含闰年 2 月与跨时区各至少 1 个。
- 给每个写接口加幂等键并重放一次，确认不产生第二笔。
- 抽一年前的一个月账单，在沙箱重算到分。
- 用 4 次重试、7 天宽限跑一次失败扣款演练。
- 给退款与改价加二次确认，记录操作人。
验收标准：十二项全过、加权总分 ≥ 4.0、季度五项工作控制在 26 小时内；达不到就先别加新功能。
使用边界与实操验收
这一篇的评分表是一人 SaaS 的自评工具，不是合规认证。
边界一：自评会偏乐观。 自己给自己打分，容易把「写了一半」记成「过了」；每项都要附一条可重放的证据。
边界二：十二项不覆盖税务合规。 税率、发票存档年限、跨境申报另有一套规则，验收表里只查发票号连续与字段完整。
边界三：沙箱不能替代真实通道。 测试时钟能模拟时间，模拟不了银行拒付与卡组织规则；每季度仍要在真实通道跑一笔小额。
边界四：权重按当前量级设定。 客单价更高或团队更大时，可审计与可运维的权重应上调，正确性未必永远是 0.35。
边界五：通过检查不等于没有漏损。 对账差异仍有 0.4%，约 0.42 行/月；验收保证的是「能被发现」，不是「不会发生」。
关键参考与核验范围
- Stripe 测试时钟 ：用于核对试用、续费与重试的时间模拟方式。
- Stripe webhook ：用于核对验签、重投与重放的基本机制。
- Stripe 幂等请求 ：用于核对写操作幂等键的语义与保留期。
- Stripe 收入回收 ：用于对照失败扣款的重试策略。
- Statecharts ：用于核对状态机与迁移守卫的一般建模方式。
以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。