高并发、多依赖、故障代价大——三个条件齐了收益最高
反应式设计投入最值的场景有三个共同特征：并发量大到同步模型扛不住、下游依赖多到任一个出问题都会影响用户、系统不可用的业务损失明显大于架构改造的投入。
电商交易链路、支付结算系统、实时数据管道、大规模消息推送——这些场景天然适合反应式。它们的共同点是"压力和故障是日常而不是意外"。
前提条件：团队对异步编程模型有基本的理解和调试能力。反应式不是写完就不管了的——异步代码的调试、追踪和监控都比同步复杂。
两类看着合理但投入产出不划算的场景
内部工具和低并发系统。 一个每天 500 个用户的后台管理系统，同步调用、单体架构、数据库直连。加 Circuit Breaker、Bulkhead、Reactive Streams？技术上可以做，但这些保护机制应对的负载和故障模式在这个量级上根本不会出现。增加的代码复杂度远超收益。
强一致性要求的事务型系统。 银行转账、库存扣减、分布式锁这类场景需要的是"要么全做要么全不做"的严格一致性。反应式的异步消息传递天然倾向最终一致性——消息可以延迟到达、可以重复、可以乱序。在强一致性场景里硬用最终一致性模型，花在补偿机制上的成本可能比同步方案还高。
方法本身会失效的三种情况
团队对异步模型不熟练。 反应式代码的调试难度是同步代码的两到三倍。回调嵌套、异步异常传播、竞态条件——如果团队没有处理这些问题的经验，引入反应式架构后 bug 会从"出在业务逻辑里"变成"出在并发和时序里"。后者更难定位、更难复现。
可观测性基础设施跟不上。 异步调用链的追踪需要分布式 tracing（如 Jaeger、Zipkin）。消息驱动的系统需要对队列深度、消费延迟、回压信号做实时监控。如果没有这些基础设施，系统出了问题你甚至不知道消息走到哪一步了。在可观测性到位之前引入反应式，等于在黑暗中做架构手术。
异步改造只做了一半。 系统的上半部分改成了消息驱动，下半部分还是同步调用。异步请求打到同步层时，线程池成了瓶颈。部分异步比全同步更危险——因为异步部分能产生的并发量远超同步部分能承受的。
该退回同步方案或简化架构的信号
你发现团队花在调试异步 bug 上的时间超过了写业务逻辑的时间。说明异步模型的复杂度超过了团队当前的消化能力。可以先退回同步方案，用简单的限流和重试替代复杂的回压和熔断。
你发现 Circuit Breaker 从来没有触发过。不是因为下游从不出问题，而是因为阈值设得太高或者根本没接监控。一个从不触发的熔断器和没有熔断器效果一样——但维护成本不一样。
你的系统在过去一年没有出过因为级联故障导致的全站不可用事件。说明当前的架构在现有负载下足够稳定。反应式改造是为了应对"压力和故障会变严重"的预期，如果这个预期不成立，改造就是提前付出了不必要的复杂度成本。