不能用gochannel.newpublisher上生产环境，因其仅为内存实现、无持久化、不支持consumergroup、无法水平扩展，不具备云原生所需的可扩缩、可观测、可恢复等能力。
别用 gochannel.NewPublisher 上生产环境——它只是测试玩具，进程一重启消息全丢，根本不算“部署”，只算本地跑通。
内存级 Pub/Sub 仅限开发验证，不能叫“云原生部署”
Watermill 的 gochannel 实现（如 gochannel.NewPublisher 和 gochannel.NewSubscriber）本质是内存切片 + channel，没有持久化、无跨进程能力、不支持 ConsumerGroup、无法水平扩展。云原生场景下所谓“部署”，至少要满足：可扩缩、可观测、可恢复、配置可注入。
- 它不提供健康检查端点，Kubernetes Liveness Probe 无法判断消息循环是否卡死
- 所有消息存在内存里，Pod 重启后历史消息彻底消失，
Persistent: true只对当前进程内重放有效 - 无法对接 Prometheus metrics 或 OpenTelemetry trace，中间件（如
TracingMiddleware）在内存模式下也形同虚设 - 多实例订阅同一 topic 时，每个实例都收到全量消息（因为没 Group 协调），不是“广播”，是“误播”
真要在云环境用内存模式，必须加三层防护
如果你坚持用 gochannel（比如 CI 流水线里的集成测试、单体服务内部模块解耦），就得自己补足云原生缺失的能力：
-
生命周期绑定：用
message.NewRouter启动，而不是手写for range；否则router.Close()无法回收 goroutine，K8s 优雅退出超时 -
错误隔离兜底：必须注册 handler 用
router.AddHandler，不能直接subscriber.Subscribe+for；否则一个 panic 就让整个消息循环停摆 -
可观测注入：手动 wrap
logger输出到 stdout，并用watermill.NewStdLogger(true, true)开启 debug 日志；否则 Kibana 或 Loki 里查不到消费延迟、重试次数等关键指标
K8s 部署内存模式的 YAML 必须显式限制资源
内存模式看似轻量，但消息积压会直接吃光 Pod 内存。不设 limit 的 gochannel 在高吞吐下等于给 OOMKiller 递刀子：
-
resources.limits.memory建议设为256Mi起，避免单个 Pod 吃掉节点内存 -
livenessProbe不能只 ping HTTP 端口，要加自定义脚本检查router.IsRunning()状态 -
env中必须传入WATERMILL_PUBSUB=gochannel这类标识，方便 Helm chart 动态切换后端
真正云原生的消息中介从来不是靠“内存快”，而是靠“故障可收敛、扩缩可预期、状态可重建”。gochannel 是个好玩具，但它连“中介”的边都没摸到——它连消息确认（Ack）语义都不支持，更别说 offset 提交、rebalance 或死信投递了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
