使用Golang实现发布订阅模式_跨模块的消息分发机制

够用但需防goroutine泄漏；用map[String][]chan Interface{}实现轻量事件总线，适用于中小型服务跨模块通信，关键要确保订阅者及时消费消息，避免缓冲区堆满导致publish阻塞。

用 map[string][]chan interface{} 实现轻量级事件总线，够用但得防 goroutine 泄漏

中小型服务内跨模块通信，比如用户注册后通知邮件、积分、风控三个模块，map[string][]chan interface{} 是最直接的解法。它不依赖外部组件，启动快、调试直观。

关键不是“能跑”，而是“不崩”。常见错误是订阅后忘记消费消息，导致 chan 缓冲区堆满，后续 Publish 调用在 select { case ch 里卡死——表面看是发布变慢，实际是某个订阅者 goroutine 停摆了。

• 每个订阅者必须自己启动 goroutine 消费通道，Broker 不负责拉取；否则一旦没人读，通道就成单向堰塞湖
• 所有 chan 必须带缓冲，例如 make(chan interface{}, 10)，空通道或无缓冲通道在高并发下极易阻塞
• 订阅时返回一个 func() 取消函数，内部用 sync.RWMutex 安全删除 map 中对应项；别靠 channel 关闭来清理，Go 里已关闭的 channel 仍可读（返回零值），无法作为生命周期信号
• 不要在 Subscribe 内部直接 go func() { for range ch { ... } }() —— 这会让 Broker 承担运行时责任，违背“只分发、不执行”原则

主题命名必须带业务前缀，否则后期根本没法拆分或限流

用 "user.created" 而不是 "created"，不是为了“规范”，是为将来留活路。当系统从单体拆微服务、或需要对用户域事件做独立监控/降级时，没前缀的主题会立刻变成运维黑洞。

真实踩坑案例：某次上线新风控策略，想只屏蔽 "order.*" 类事件做灰度，结果发现所有模块都往 "timeout" 这个裸主题发，根本分不清是支付超时还是数据库查询超时。

立即学习“go语言免费学习笔记（深入）”；

• 推荐格式："{domain}.{action}"，如 "payment.refunded"、"notification.sent"
• 避免动词泛化：不用 "done"、"finished"，而用 "user.verified" 这类具象动作
• 如果用 Redis Pub/Sub 或 Kafka，主题名会直接映射到频道/Topic 名，此时前缀还影响 ACL 权限配置和网络路由策略

别用 interface{} 传消息体，结构体 + JSON 序列化才是生产底线

写 broker.Publish("user.created", map[string]interface{}{"id": 123, "name": "foo"}) 看似省事，但很快会在下游遇到 panic: interface {} is map[string]interface {}, not *UserCreatedEvent。类型断言失败不是小问题，是消息契约断裂的起点。

更隐蔽的问题是：不同模块对同一事件字段理解不一致。A 模块认为 "ts" 是秒级时间戳，B 模块按毫秒解析，结果积分延迟发放两小时。

• 定义明确结构体，如 type UserCreated struct { ID int64 `json:"id"` CreatedAt time.Time `json:"created_at"` }
• 发布前统一 json.Marshal 成字节流，订阅端再 json.Unmarshal；中间不透传原始 interface{}
• 如果性能敏感（如每秒万级事件），可用 gogoprotobuf 或 msgpack 替代 JSON，但结构体定义这一步不能跳

同步阻塞型 Publish 在生产环境等于埋雷

看到代码里 for _, ch := range subs { ch 就该警觉——这不是发布，是串行调用。只要有一个订阅者处理慢（比如发 HTTP 请求卡住），整个发布流程就拖垮，上游 API 响应时间飙升。

真正解耦，是让发布者“扔完就走”，不等任何人。Watermill、NATS 等库默认异步，手写也必须加 goroutine 层。

• 正确姿势：对每个 ch 启一个匿名 goroutine，用 select { case ch
• 加 default 分支不是为了优雅降级，是防止 goroutine 永久挂起；没有它，泄漏的 goroutine 会吃光内存
• 如果下游必须可靠投递（如扣款成功通知），那就别用手写 Pub/Sub，直接切到 RabbitMQ/Kafka，用 ack + DLQ 机制兜底

最常被忽略的一点：消息丢失是否可接受，决定了你该用内存通道还是消息中间件。别在日志里写“已发布事件”，结果连 Redis 都没连上——那只是自我安慰。