watermill本身不支持安全的纯进程内pubsub，gochannel仅用于测试调试，缺乏持久化、ack、重试等生产级保障；真正可靠的本地解耦应使用router内存路由或原生chan+sync.map方案。
Watermill 本身不支持纯进程内（in-process）的本地 PubSub，强行用 GoChannel 或 Direct 作为“本地分发器”极易引发消息丢失、重复消费、无序、panic 等问题——这不是配置问题，而是设计边界问题。
为什么 GoChannel 不是安全的本地 PubSub
GoChannel 是 Watermill 提供的测试/调试用消息传输器，它不提供任何持久化、重试、ACK、消费者组或并发安全保证。它的 Publisher.Publish 是同步写入 channel，Subscriber.Subscribe 是同步读取；一旦消费者 panic、处理超时或未及时接收，channel 就会阻塞或丢弃消息（取决于 buffer 大小）。真实业务中无法依赖它做可靠分发。
- 没有消息确认机制：消费者 crash 后消息直接消失
- 无背压控制：生产者持续
Publish而消费者卡住 → channel 满 → 后续Publish阻塞或 panic（取决于是否带 buffer） - 无法跨 goroutine 安全复用：多个
Subscriber实例订阅同一 topic 时行为未定义 - 不支持
SubscribeOne或Consume的语义封装，需手动管理 goroutine 生命周期
真正可用的“进程内 PubSub”替代方案
如果你的目标是：在单个 Go 进程里解耦组件、避免直接调用、支持异步+失败重试+顺序保障，那么应该放弃 Watermill 的 transport 层，改用更轻量、可控的原生机制：
- 用
chan Message+sync.Map做 topic 路由：适合极简场景，但需自行实现重试、死信、buffer 控制 - 用
github.com/ThreeDotsLabs/watermill/message/router的Router+ 内存PubSub：Watermill 自带的message.Router可以在内存中路由消息到不同Handler，绕过 transport 层，本质是事件总线（Event Bus）模式 - 直接用
github.com/oklog/run+chan+context构建可取消、可等待的内部消息流：对可靠性要求高时最可控
示例（基于 Router 的内存事件分发）：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
router, err := message.NewRouter(message.RouterConfig{})
if err != nil {
panic(err)
}
// 注册一个“内部 handler”，不走任何 transport
router.AddHandler("user.created", "user_topic", &NoOpSubscriber{}, "notification", notificationHandler)
// 发布消息（完全内存内）
msg := message.NewMessage(uuid.NewString(), []byte(`{"user_id":"123"}`))
router.Publish("user_topic", msg) // 同步触发 notificationHandler
注意：NoOpSubscriber 是 Watermill 提供的空实现，仅用于满足接口；这里 router.Publish 不经过任何 channel 或 broker，直接调用 handler。
如果必须和 Watermill 生态共存，如何最小侵入地桥接
你已有 Watermill 的 Kafka/NATS 流程，只想对部分逻辑做“本地短路”，例如：日志审计、缓存刷新等副作用操作。这时应避免新增 transport，而是用 Middleware 或 Handler 内部触发：
- 在 Kafka handler 中，用
go func() { ... }()启动本地 side effect（注意 context 传递和错误忽略风险） - 用
message.Router的router.AddMiddleware注入通用钩子，对特定 header（如X-Local-Only: true）的消息跳过 publish，直接 dispatch 到本地函数 - 绝不混用
GoChannel和 Kafka transport 订阅同一 topic：Watermill 不保证跨 transport 的消息顺序与交付语义
关键判断点：只要你的场景需要“至少一次”或“有序”保障，就不要把 GoChannel 当作生产级本地 PubSub。
Watermill 的定位是“分布式消息系统抽象”，不是“进程内事件总线”。选型错位比配置错误更难调试——尤其是当消息在本地看似正常、上线后却批量丢失时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
