背景
社区里我们最近把「写库 + 发消息」这条链路的正确性讨论得很充分：本地消息表 vs Outbox vs 事务消息（#589）、幂等该在 commit 前还是 commit 后做（#869）、消费失败后死信与人工补偿的分工（#82）、半截链路的补偿边界（#450）。这些讨论都默认了一个前提——这条链路应该走异步。
但我在带团队做订单/履约/营销链路的时候，越来越频繁地遇到另一种情况：团队把"写业务库 + 通知下游"默认异步化，结果为了把异步链路做对，付出的成本比同步调用高一个量级，还多了一整类新的故障模式（消息重复、半截状态、补偿失败、对账不平）。
我统计了一下自己见过的项目：
- 链路 A：订单创建 → 写库存 → 发短信。异步化后，消息重复率 0.3%，补偿失败率 0.05%，但用户感知到的"订单创建成功了但短信没收到"工单率反而比同步调用高（同步调用时短信失败会直接报错给用户重试）。
- 链路 B：支付回调 → 写账单 → 通知对账系统。异步化后，对账系统延迟从 200ms 涨到 3~5s，对账系统的"实时性"承诺被打破。
- 链路 C：优惠券核销 → 扣库存 → 通知风控。这条确实需要异步，因为风控侧有 50ms 的硬超时，同步调用会拖垮核销主链路。
常见分歧 / 几种做法
我见过团队在这件事上大致分三派：
派一：能异步就异步。 理由：解耦、削峰、未来扩展方便。代价：需要本地消息表 / Outbox、幂等表、死信队列、补偿任务、对账任务——一整套基础设施。
派二：默认同步，异步是例外。 理由：同步调用的失败是显式的、可重试的、可被用户感知的；异步把失败藏起来了，需要额外的基础设施才能"找回"。代价：调用方要处理下游超时/降级，链路延迟叠加。
派三：看下游 SLA。 下游对延迟不敏感（>1s 可以）→ 异步；下游对延迟敏感（<50ms）→ 同步；中间态（100ms~1s）→ 看下游能否容忍"最终一致"。
我的倾向与理由
我站派二偏派三：默认同步，异步是显式的、需要论证的例外。理由有三：
-
异步的正确性成本是结构性的，不是配置性的。幂等表、死信、补偿、对账——每一件都是"必须做对否则就是数据事故"的组件，而且它们之间的交互（补偿失败怎么办？对账不平怎么修？）本身又是一个分布式问题。同步调用的失败至少是"单点"的，异步的失败是"链路"的。
-
用户感知层面，同步失败往往比异步"静默成功"更友好。"短信发送失败，请重试" 比 "订单创建成功但短信没收到，联系客服" 的体验好得多。异步把失败藏进后台，需要额外的补偿/对账/客服链路才能"找回"——这条找回链路本身又可能失败。
-
团队规模与基础设施成熟度是关键变量。10 人团队 + 没有专职 SRE，做异步的正确性成本远高于同步；50 人团队 + 有消息中间件团队 + 有对账系统，异步的收益才真正大于成本。这不是技术选型，是组织选型。
想听大家在什么场景下怎么选
抛几个具体场景，想听听你们的真实判断：
- 下游是"只读查询"还是"写操作"：写下游（扣库存、发短信）和读下游（查配置、查风控）的同步/异步决策会不同吗？
- 下游 SLA 是 50ms 硬超时：你一定会选异步吗？还是宁可同步调用失败也不引入异步链路？
- 团队 5 人 vs 50 人：同样的业务需求，团队规模会改变你的同步/异步决策吗？
- "异步化"的决策权：在你们团队，"这条链路要不要异步化"是架构师拍板，还是开发者自己判断？判断标准是文档化的还是口口相传的？
- 有没有"从异步改回同步"的真实案例：什么信号让你们决定"这条链路不该异步"？
我自己最没想清楚的一点是："下游对延迟不敏感"这个判断，到底是谁的 SLA？是下游自己声明的，还是上游猜的？ 如果下游的 SLA 是"最终一致"，那上游异步化是合理的；但如果下游其实需要"实时一致"，只是没声明，那上游异步化就是在给下游埋雷。这个 SLA 的对齐机制，在你们团队是怎么做的？