业务上"最终一致"，你们敢给用户承诺多久？

背景：我做分布式 10 年，带团队落地过订单、支付、库存三条强一致链路。每次方案评审，架构师都爱说一句"我们做最终一致就够了"。这句话本身没错，错在它把"最终"两个字悄悄藏了起来——最终，到底是几毫秒、几秒、几分钟甚至几小时？ 这个窗口期一旦没人认领，用户就会替你去认领。

举个我踩过的数：某次退款链路用 outbox + MQ，正常 200ms 内账务落库，P99 大概 1.2s，看起来很美。但有一次下游账务服务 GC 抖动叠加消费积压，同一笔退款 47 分钟后才到账。用户没等到"最终一致"，等到的是客服工单。事后复盘，我们整个团队没人能回答"我们的最终一致 SLA 是多久"——因为从设计那天起，就没人把它当成一个必须承诺的数字。

常见分歧 / 几种做法：

1. 强一致党：关键链路直接同步调用 + 本地事务，拒绝任何异步。代价是 RT 和吞吐都下降，可用性跟着打折（一次下游抖动整条链路雪崩）。
2. 最终一致党：全异步 + outbox + 幂等 + 对账。吞吐高、隔离好，但"最终"没有 SLA，靠事后补偿兜底，用户感知到的延迟是黑的。
3. 分级党：按业务把一致性分成"秒级 / 分钟级 / 天级"三档，每档配不同补偿与对账。但分级标准往往拍脑袋。

我的倾向：我站分级党，但坚持"窗口期必须是一个被写进 SLA、有监控、有告警、有补偿预算的数字"。理由三条：

• 一致性窗口不是技术选型，是产品决策。用户愿意等的时长，决定你用同步还是异步、要不要出对账页、要不要给用户"处理中"的中间态。
• 窗口期一旦量化就能配监控：outbox 从入队到落库的耗时 P99 就是一个可观测指标，超阈值就该告警，而不是等用户投诉。
• 有数字才能算成本：分钟级的最终一致，补偿和对账的存储、算力、人力成本可以估算；"最终"没有数字，成本就是无底洞。

想听大家：

• 你团队里"最终一致"的窗口期，有没有被明确写进 SLA？大概多少？
• 业务方说"这里可以异步"，你怎么判断他说的"可以"是秒级可接受，还是能容忍分钟级延迟？
• 有没有踩过"最终一致变成永久不一致"的坑？你们的对账 / 补偿机制怎么兜底？
• 对 C 端和 B 端，你们给的窗口期一样吗？为什么？

期待看到具体数字和真实事故，而不是"我们用的是最终一致"这种正确但没用的答案。