Go语言中没有Fanout交换机，这是RabbitMQ等AMQP系统的概念；若需进程内多消费者广播，须手动实现fan-out，因Go channel本质是点对点通信原语。
Go 语言里没有“Fanout 交换机”这个东西——这是 AMQP（如 RabbitMQ）的概念，不是 Go 原生 channel 的能力。 直接把 RabbitMQ 的 Fanout Exchange 语义套到 Go channel 上，会导致严重误解和错误设计。你需要先分清：是想在 Go 进程内做多消费者广播？还是在多个 Go 进程间共享一个消息队列的 Fanout 行为？两者解法完全不同。
Go 内部用 channel 实现“每个 goroutine 收到全量副本”必须手动 fan-out
Go 的 chan 是点对点通信原语， 操作只能被一个 goroutine 成功接收。如果你把同一个 <code>ch 同时传给 processEmail 和 processPagerDuty，它们会竞争读取——每次只有一方拿到值。
- 正确做法是启动一个中央分发 goroutine，从源 channel 读一次，再分别写入多个专用 consumer channel
- 每个 consumer goroutine 独占一个自己的 channel，比如
emailCh、pagerCh - 注意 consumer channel 的缓冲区大小：若处理慢而发送快，无缓冲 channel 会阻塞分发 goroutine；建议用带缓冲 channel 或配合
select+default防止积压 - 别忘了关闭逻辑：源 channel 关闭后，要通知所有 consumer channel 结束（例如通过额外的
donechannel 或同步关闭信号）
多个 Go 进程监听同一个 RabbitMQ Fanout Exchange 才能天然全量独立
如果你说的是多个独立的 Go 服务进程（比如部署了 3 个 alerter 实例），都连到同一个 RabbitMQ 的 Fanout Exchange 并绑定各自 queue，那它们天然就能各自收到全量副本——这是 AMQP 协议层保证的，跟 Go 无关。
- 每个进程需创建自己独立的 connection 和 channel，绑定到同一个 exchange
- 确保每个进程声明的是**独占 queue**（
exclusive: true）或**自动删除 queue**（autoDelete: true），避免多个实例共用一个 queue 导致消息被轮询消费 - 不要在 Go 层尝试“复用” RabbitMQ connection：connection 是昂贵资源，每个进程持有一个即可；goroutine 复用 channel（AMQP channel）是安全的
- 出错时检查 RabbitMQ 管理界面：确认每个 queue 的 bind count 是 1，且 message rates 显示每条消息都被 fan-out 到全部 queue
误用 SO_REUSEPORT 无法解决“多进程广播”问题
有人看到 SO_REUSEPORT 能让多个 Go 进程监听同一端口，就以为它也能让多个进程“同时收到同一份网络数据包”——这是常见误解。SO_REUSEPORT 只影响 accept() 阶段的连接分发，不改变数据包送达逻辑：一个 TCP 数据流只会由内核交给其中一个进程处理，不会复制给所有进程。
-
SO_REUSEPORT适用于 HTTP 服务器横向扩容，不是消息广播机制 - 它和 RabbitMQ Fanout、Go channel fan-out 完全不相关，混用会导致架构混乱
- 若你真需要跨进程广播，应走消息中间件（RabbitMQ/Kafka）、或用 Unix domain socket + 自定义协议、或用 Redis Pub/Sub，而不是硬啃 socket 选项
最容易被忽略的一点：fan-out 的“全量”是否包含**顺序一致性**。RabbitMQ Fanout 能保证每个 queue 收到全量，但不承诺各 queue 之间消息到达顺序一致；Go 内部 fan-out 分发 goroutine 是串行写入各 consumer channel 的，顺序可预期。如果你的业务依赖严格时序（比如状态变更必须按先后执行），那就不能只靠 fan-out，得引入序列号、版本号或外部协调器。
