Go-Micro Broker 的 publish 默认同步阻塞，仅表示消息发至broker而非被消费；subscriber需手动goroutine异步处理，且须选型支持持久化/ACK的broker（如NATS JetStream）并显式序列化数据。
Go-Micro 的 Broker 接口确实提供了发布/订阅抽象，但它不是开箱即用的“异步消息中间件”，而是一个薄层封装——真正决定是否异步、是否可靠、是否有序的，是底层选用的 broker 实现（比如 redis、nats、rabbitmq）以及你如何调用它。
Go-Micro Broker 的 publish 是同步阻塞还是异步？
broker.Publish() 默认是同步调用：它会等待底层 broker 客户端完成发送（例如 NATS 的 publish 或 Redis 的 PUBLISH），但不保证消息被消费——这取决于 broker 本身是否支持持久化、确认机制等。它不提供回调或 context 超时控制（除非你手动包装）。常见误区是以为调用完就“发出去了”，结果在 Redis broker 下遇到连接中断时静默失败，日志里只有一行 publish error: dial tcp: i/o timeout。
-
broker.Publish()返回 error，必须检查；忽略等于放弃可靠性 - 如果用
redisbroker，消息不持久化，服务重启后未消费消息丢失 -
natsbroker 默认无 ACK，需启用 JetStream 并配置ack才能保证至少一次投递 - 不要依赖
broker.Publish()的返回时间判断业务逻辑完成与否——它只代表“发到 broker”，不代表“被消费”
如何让 subscriber 真正异步处理消息？
Go-Micro 的 broker.Subscribe() 注册的是一个 handler 函数，框架内部会启动 goroutine 调用它，但这只是“接收端并发”，不是“业务处理异步化”。如果你在 handler 里直接调用数据库写入或 HTTP 请求，出错会导致消息被丢弃（默认无重试）、或阻塞后续消息（取决于 broker 实现的 prefetch 行为）。
- 务必在 subscriber handler 中启动新 goroutine 处理耗时逻辑：
go func() { /* 处理逻辑 */ }() - 使用带缓冲的 channel 或 worker pool 控制并发数，避免 goroutine 泛滥（如每秒 1000 条消息，每条都
go handle()很危险） - subscriber 启动时要传
broker.Queue("my-queue")（尤其用nats或rabbitmq），否则多实例会重复消费同一消息 - NATS 默认不支持 consumer group，需用
QueueGroup+ JetStream 才能实现负载均衡消费
为什么本地开发用 redis broker 总收不到消息？
因为 Go-Micro 的 redis broker 实现（v4 及以前）默认使用 redis.PubSub，而 Redis 的 Pub/Sub 是纯内存、无持久化的——订阅者必须在发布前就在线，且连接断开后无法回溯。你在 main 函数里先 broker.Publish() 再 broker.Subscribe()，消息就丢了。
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段建议换用
nats（轻量、自带 JetStream 持久化）：micro.NewService(micro.Broker(nats.NewBroker())) - 若坚持用 Redis，改用第三方
redis-streamsbroker 实现（非官方），或自己基于github.com/go-redis/redis/v8的XADD/XREADGROUP封装 -
redisbroker 的Subscribe方法实际调用的是redis.PubSub.Receive()，该方法阻塞等待，但不支持重连——网络抖动后整个 subscriber 就卡死
如何跨服务传递结构化数据而不序列化出错？
Go-Micro Broker 不做序列化，它把 broker.Message.Body 当作 raw []byte 直接交给底层 client。如果你直接传 struct，会 panic：json: cannot encode type struct {...}。必须显式序列化。
- 统一用
json.Marshal()序列化后再传给broker.Publish()，subscriber 侧用json.Unmarshal() - 避免用
gob，不同 Go 版本或 struct 字段变更会导致解码失败 - 在消息体开头加 version header（如
msg.Header["version"] = "v1"），方便未来兼容升级 - 不要依赖
broker.Message的Header传敏感信息——NATS 和 Redis 都明文传输，无加密
Broker 抽象的“简单”背后是大量隐含契约：你得清楚每个 broker 实现的语义差异，还得自己补足重试、死信、监控这些生产必需能力。别把它当成 Kafka 替代品用——它更像一层适配器，真正的异步可靠性，得靠选对 broker + 写对代码。
