直接回答

发布-订阅模式在大规模下的主要缺点是：消息量随订阅者数量乘性放大、系统行为变得难以预测和调试、以及消息可靠性语义（顺序、去重、投递保证）的成本急剧上升。解耦换来的灵活性，在规模面前会转化为运维和治理负担。

展开解析

具体痛点：扇出放大——一条事件被几十个订阅方消费，broker 的吞吐和存储压力按订阅数线性增长；可观测性下降——事件链条长、触发关系隐式，故障时难以回答"谁发布的、谁受影响"，必须投入分布式追踪和事件目录治理；背压与故障扩散——消费慢的订阅者造成分区积压，毒消息反复重试会拖垮消费组，需要死信队列和隔离；语义保证变贵——全局顺序基本不可行，只能分区内有序，消费者必须幂等以应对 at-least-once 重复投递；schema 演进难——生产者不知道全部消费者，字段变更可能悄悄破坏下游。应对：合理划分 topic、消费端幂等+限流、事件契约治理（schema registry）、容量按订阅数规划。追问：何时该退回点对点请求调用、如何控制事件风暴。