异步优先还是同步优先：高并发系统里我看到的两种极端做法

背景：最近复盘几条链路，发现同一团队里对「要不要异步」几乎没有统一判断标准。有人把每个下游调用都塞进线程池 + 队列，理由是「别阻塞主线程」；有人坚持一个请求里能同步调用就同步调用，理由是「异步把故障藏起来了，排障时根本看不全链路」。两边都有道理，也都在高并发场景下翻过车。

常见分歧 / 几种做法：

1. 全异步优先：所有 IO 都走异步 / 消息队列，主链路只做编排。优点是吞吐高、能优雅降级；代价是调用链断裂、重试与幂等要自己兜、调试成本翻倍。
2. 同步优先 + 超时兜底：默认同步，只在明确「可丢 / 可延迟」的旁路（日志、埋点、通知）走异步。优点是心智模型简单、trace 完整；代价是任何一个下游抖动都会直接打穿 P99。
3. 混合：按「是否阻塞用户响应」切分，同步链路只保留强一致的部分，弱一致的全部异步化 + 对账补偿。

我的倾向：以「用户是否等待这个结果」作为唯一判据——用户在等的就必须同步 + 超时 + 熔断兜底；用户不等的一律异步 + 幂等 + 死信兜底。理由是我见过太多「为了异步而异步」的链路，最后排查一次超时要翻四套日志。

想听大家聊聊：你们在什么场景下会故意放弃异步？又在什么场景下被迫全异步、然后付出了什么代价（重试风暴？消息积压？对账延迟）？如果有「看起来该异步、但同步反而更稳」的反例，非常想看。