把同步接口改成异步/消息化，到底是解耦削峰，还是把延迟问题藏进了黑盒？

背景

我带了 15 年后端，一半时间在做高并发链路。最近帮一个团队做容量评审，他们面对一个下单接口 P99 从 80ms 抖到 1.2s 的问题，给出的方案是"把下单同步流程拆成消息队列异步化，前端改成轮询结果"。我当场泼了冷水：你这不是把 1.2s 的 P99 消掉了，你是把"用户等 1.2s 拿到确定结果"换成了"用户不知道要等多久、也不知道最后成没成"。这到底是解耦，还是把延迟问题藏进了一个没有 SLA 的黑盒？

常见分歧，我看到的至少有四种做法

1. 激进异步派：能异步就异步，接口只负责"受理+返回流水号"，重活全丢 MQ。理由是把同步链路上的 GC、下游 RPC、DB 锁竞争全部从"用户等待路径"上挪走，P99 立刻好看。代价是用户拿到的不再是"结果"，而是"一个承诺"。
2. 同步保真派：核心交易接口必须同步返回确定结果，异步只用在可容忍最终一致的旁路（积分、通知、埋点）。理由是对用户而言，"确定要多久"永远比"可能很快也可能很慢"更可预期。
3. 两段式派：同步做"校验+占位"，异步做"扣减+落库"，中间用幂等键+状态机兜底。听起来最稳，但状态机的复杂度、幂等键的粒度、超时回滚的边界，往往比原来的同步链路还难写对。
4. 不异步、只治理派：先别动同步/异步的架构，先把同步链路里真正的 P99 凶手（连接池、慢查询、GC、下游抖动）一个个修掉。很多团队没修完就急着异步化，本质是拿架构变更掩盖了没查清的根因。

我的倾向与理由

我站第 4 种为前置、第 3 种为兜底。核心判据只有一条：用户拿到的是"确定结果"还是"一个承诺"。如果业务语义要求"此刻就要知道成没成"（支付、扣库存、下单确认），那异步化就是在偷换问题——你没有消除延迟，你只是把延迟的可见性从"用户能感知"变成了"用户感知不到但系统在背债"。我见过太多"异步化后 P99 达标"的验收报告，半年后翻出来全是"消息堆积""状态机卡死""幂等键冲突"，根因是当初没回答"异步之后，用户到底在等什么"。

想听大家的

• 你们团队里"同步改异步"的决策门槛是什么？是 P99 超标就改，还是先证明同步链路已经没救？
• 两段式/状态机你们怎么设计超时回滚的边界？幂等键的粒度卡在请求级还是业务级？
• 有没有人做过"先异步、后回滚到同步"的反向重构？什么信号让你意识到异步是错的？
• 最后一个私货：你们验收"异步化改造成功"的指标，除了 P99 下降，还有没有把"用户拿到确定结果的时间"单独列出来？我越来越觉得这个才是该盯的。