Go中实现Pub/Sub模式需通过事件中心解耦发布者与订阅者，可用channel+map轻量实现或Watermill等成熟库；主题命名应带业务前缀，消息用结构体序列化，避免同步阻塞与goroutine泄漏。
在 Go 中实现发布-订阅（Pub/Sub）模式，核心是用通道（channel）或第三方库构建松耦合的消息分发机制，让发布者不依赖具体接收者，接收者也不感知发布者存在。关键在于引入“事件中心”或“主题管理器”作为中间层。
用 channel + map 实现轻量级 Pub/Sub
适合中小型应用，无需外部依赖。本质是维护一个主题（string）到接收通道（chan interface{}）的映射，并为每个主题启动独立 goroutine 转发消息。
- 定义 Broker 结构体，包含 map[string][]chan interface{} 存储所有订阅者
- Publish 方法遍历该主题下的所有通道，用 select + default 避免阻塞（防止接收方未及时读取导致发布卡住）
- Subscribe 返回一个只读通道，同时注册到对应主题；Unsubscribe 需支持从 slice 中安全移除（注意并发写）
- 示例中可加 sync.RWMutex 保护 map 读写，或改用 sync.Map 提升并发性能
用第三方库：github.com/google/uuid + github.com/ThreeDotsLabs/watermill
生产环境推荐使用成熟库。Watermill 是专为 Go 设计的异步消息处理框架，原生支持 Kafka、NATS、Redis、内存通道等后端，且内置 Pub/Sub 接口抽象。
- 初始化时选择消息中间件（如 watermill-mem 用于本地测试），获得 Publisher 和 Subscriber 实例
- 发布者调用 Publisher.Publish(topic, msg)，消息自动序列化并路由
- 订阅者通过 Subscriber.Subscribe(ctx, topic) 获取消息流，按需处理
- 支持中间件（日志、重试、验证），也支持消息确认（ack/nack）、死信队列等高级特性
解耦的关键设计点
真正的解耦不是“不用 import 对方包”，而是运行时无直接调用关系。发布者只认主题名，接收者只认主题名，两者甚至可部署在不同进程。
立即学习“go语言免费学习笔记（深入）”；
- 主题命名建议带业务域前缀，例如 "user.created" 或 "order.shipped"，便于权限与路由控制
- 消息体统一用结构体 + JSON 序列化，避免接口{}带来的类型断言风险
- 接收方应自行处理失败：超时、重试、降级或记录到 DLQ（死信队列），不要让发布方承担错误传播责任
- 避免在订阅回调里做耗时操作（如 HTTP 请求、DB 写入），应转发到 worker pool 或异步任务队列
常见陷阱与规避方式
初学者容易把 Pub/Sub 写成同步调用或通道泄漏，导致内存暴涨或 goroutine 泄露。
- 不要让订阅通道无限缓存：用带缓冲的 chan（如 make(chan T, 10)），或配合 context.WithTimeout 控制生命周期
- goroutine 启动后必须有退出路径，例如监听 ctx.Done() 并关闭通道，否则无法 GC
- 不要在 Subscribe 中直接启动长循环读通道 —— 应由使用者自己启动，Broker 只负责分发
- 测试时可用 membroker（Watermill 内置）替代真实中间件，实现单元测试隔离
