够用但需防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语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐格式：
"{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 都没连上——那只是自我安慰。
