Go微服务事件通知须用异步解耦机制，首选NATS（轻量、低延迟、原生支持），发布需序列化+版本化主题+Flush，消费需手动Ack+重试+幂等；强序/持久化场景选Kafka并设PartitionKey。
Go 微服务间事件通知不能靠 HTTP 轮询或直接调用，必须用异步、解耦、带重试和幂等保障的机制。核心路径是：生产者发事件 → 消息中间件（如 Kafka / NATS / Redis Streams）→ 消费者订阅处理。
用 nats.go 发布/订阅事件最轻量且适合内部微服务
NATS 是 Go 生态最原生支持的事件总线，无依赖、启动快、延迟低。它不保证持久化，但对“服务发现变更”“缓存失效通知”这类最终一致性场景足够可靠。
常见错误是直接用 Conn.Publish() 发送原始结构体——NATS 只收 []byte，必须序列化：
- 统一用
json.Marshal()，别用gob（跨语言不兼容） - 主题名加版本前缀，例如
v1.user.created，避免消费者升级时解析失败 - 发布前检查
conn.Status()，连接断开时不要静默丢弃事件
conn, _ := nats.Connect("nats://localhost:4222")
data, _ := json.Marshal(map[string]interface{}{"id": 123, "email": "a@b.c"})
conn.Publish("v1.user.created", data)
conn.Flush() // 必须调用，否则可能缓冲未发出消费端必须实现 Ack() + 重试 + 幂等判断
默认 nats.Subscribe() 是 auto-ack 模式，消息一到就删，出错就丢。生产环境必须用手动确认：
立即学习“go语言免费学习笔记（深入）”；
- 用
SubscribeSync()或ChanSubscribe()配合Msg.Ack()控制生命周期 - 处理失败时调用
Msg.NakWithDelay(5 * time.Second)延迟重投，避免雪崩 - 在数据库写入前查
event_id是否已存在（推荐用唯一索引+忽略冲突），而不是只依赖消息去重
sub, _ := conn.SubscribeSync("v1.user.created")
for {
msg, err := sub.NextMsg(5 * time.Second)
if err != nil { continue }
var evt map[string]interface{}
json.Unmarshal(msg.Data, &evt)
if !isEventProcessed(evt["id"].(string)) {
processUserCreated(evt)
msg.Ack()
} else {
msg.Ack() // 已处理仍要 ack，否则会反复投递
}
}跨语言或需持久化的场景，改用 kafka-go 并注意分区键
Kafka 适合审计日志、订单状态流等强顺序+高留存需求。Go 客户端 kafka-go 的坑在于：不设 PartitionKey 会导致同一业务实体（如 user_id=1001）被散列到不同分区，破坏事件顺序。
- 关键业务字段必须作为
PartitionKey，例如订单事件用order_id字节数组 - 消费者组名（
GroupID）要固定，重启后才能从上次 offset 继续 - 不要用
WriteMessages()单条发，批量用Writer.WriteRecords()提升吞吐
w := kafka.Writer{
Addr: kafka.TCP("localhost:9092"),
Topic: "user-events",
}
w.WriteMessages(context.Background(),
kafka.Message{Value: data, PartitionKey: []byte("user_1001")},
)事件不是万能胶——状态同步类操作（如库存扣减）仍该走同步 RPC + Saga 补偿；事件只负责「通知发生了什么」，不承担「确保结果达成」。最容易被跳过的点是：没给每个事件定义明确的 schema 版本管理和消费者兼容策略，导致一个服务升级后，其他服务解析 panic。
