必须手动调小ReceiverQueueSize和MaxPendingChMessages：默认1000预取量在跨地域场景下极易导致内存爆满或消息堆积，实测ReceiverQueueSize=100+MaxPendingChMessages=50为安全起点，配合Shared订阅与AckID机制保障全球高并发下的吞吐与可靠性。
直接用 consumer.Receive() 处理全球分布式高并发请求，不出半天就会内存爆满或消息堆积失控。核心矛盾不在连接数，而在 Go 客户端默认的阻塞拉取模型和 Pulsar 的流式分发机制不匹配——尤其跨地域时网络延迟放大了缓冲失控风险。
为什么 ReceiverCapacity 和 ReceiverQueueSize 必须手动设小
很多人照抄示例用默认 ReceiverQueueSize=1000，在跨机房场景下等于主动邀请 Broker 把几万条消息全塞进本地内存。Broker 不知道你处理慢，它只按预取量硬推；而 ReceiverCapacity（旧版参数名）已被弃用，新版必须用 ReceiverQueueSize 控制预取上限。
-
ReceiverQueueSize=100是实测安全起点：足够掩盖单次 RTT 波动，又不会让亚洲节点消费卡顿时，把欧洲 Broker 推来的消息堆满 2GB heap - 搭配
MaxPendingChMessages=50：这是 channel 缓冲区硬限，防止 worker goroutine 拉太快但业务逻辑卡住，导致msgChan内部缓冲无限膨胀 - 若用
Shared订阅且部署 10 个实例，每个实例的ReceiverQueueSize独立生效，总预取量 = 10 × 100 = 1000，比单实例开 1000 安全得多
Shared 订阅 + 显式 AckID 是跨区域吞吐唯一可行路径
Exclusive 或 Failover 订阅强制单消费者，根本无法应对全球多活部署；Shared 允许多实例并行消费同 topic，但代价是你必须自己控制 Ack 节奏，否则消息会重复或丢失。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别用
consumer.Ack(msg)：它依赖 msg 对象生命周期，跨 goroutine 传递易出 panic - 必须用
consumer.AckID(msg.ID())：ID 是轻量值类型，可安全传给任意 worker - 失败重试要带
consumer.NackID(msg.ID(), pulsar.NackRedeliverDelay(30*time.Second))，避免瞬时抖动触发雪崩重投 - 注意：
KeyShared虽能保序，但全球部署时 key 分布不均会导致某些实例负载畸高，除非业务强依赖单 key 顺序，否则优先选Shared
geo-replication 场景下必须关掉自动 dedup 和调低 ack quorum
跨地域复制链路长、延迟高，Broker 默认的去重和强一致 ack 会拖慢整个 pipeline。生产环境实测发现，开启 brokerDeduplicationEnabled=true 后，东京→硅谷复制延迟从 80ms 升到 1.2s。
- 关掉客户端侧 dedup：
producer.WithDisableBatching(true)+producer.WithCompressionType(pulsar.NoCompression)，让去重逻辑下沉到 Broker 层统一做 - 降低 ack quorum：
managedLedgerDefaultAckQuorum=2（非 3），在容忍单点故障前提下换回延迟——Pulsar 的分层存储已保证最终一致性 - 为防跨域网络分区，consumer 初始化时加
client.WithOperationTimeout(30*time.Second)，避免 connect 卡死阻塞整个 goroutine 启动流程
最容易被忽略的是 MaxPendingChMessages 和 ReceiverQueueSize 的协同关系：前者管 channel 缓冲，后者管 Netty ByteBuf 预取，两者都超限时，客户端会静默丢弃新消息而不报错。上线前务必用 pulsar-admin topics stats 观察 msgBacklog 和 unackedMessages 是否持续增长——那说明你的缓冲水位设置已经失守。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
