go中channel做消息总线易卡死，因无缓冲channel要求收发双方同步就绪，否则发送方永久阻塞；有缓冲时满则阻塞，且不支持动态增删监听者、无重试和持久化机制。
Go 里用 channel 做消息驱动，为什么容易卡死？
直接用 chan 当消息总线，不加缓冲或超时控制，服务启动后一发消息就阻塞。根本原因是 Go 的 channel 默认是同步的——发送方会一直等接收方就位。
- 无缓冲 channel（
make(chan string)）必须收发双方同时准备好，否则阻塞 - 用
select+default可避免死锁，但会丢消息；加time.After更稳妥 - 生产环境别用裸 channel 做跨服务通信，它不提供重试、持久化、ACK 机制
选 go-micro 还是 go-kit？实际项目怎么定？
两者都过时了：go-micro v3+ 已转向插件化架构，官方不再维护旧版；go-kit 更像工具集，没内置消息中间件集成。现在主流是自己组合 github.com/segmentio/kafka-go 或 github.com/rabbitmq/amqp + context 控制生命周期。
- 要快速验证逻辑？用
kafka-go+confluent-kafka-go搭本地 Kafka，consumer.ReadMessage阻塞读取，配合ctx.Done()优雅退出 - 轻量级场景？
amqp库更简单，但注意amqp.Publishing的ContentType和DeliveryMode必须显式设为2（持久化） - 别信“开箱即用”的框架封装，它们常把
context.WithTimeout错误地套在 consumer loop 外层，导致整个消费循环被中断
context.Context 怎么传进 goroutine 才不漏 cancel？
最常见错误是把顶层 ctx 直接传进 goroutine，然后在 goroutine 里调用 context.WithCancel —— 新 ctx 的 cancel 函数根本没人调用，goroutine 永远不会停。
- 正确做法：在启动 goroutine 前，用
ctx, cancel := context.WithCancel(parentCtx)，再把ctx和cancel分开传入；服务 shutdown 时调cancel() - 消费消息时，每个
msg处理应派生独立子 ctx：msgCtx, _ := context.WithTimeout(ctx, 30*time.Second)，防止单条消息卡住整条 consumer - 切忌在
defer cancel()后还操作 channel 或 DB，cancel 触发后ctx.Err()立即返回，后续操作可能 panic
消息体序列化用 json 还是 protobuf？
Go 默认用 encoding/json，但字段名大小写、空值处理、嵌套 map 性能差，且无法跨语言兼容。Protobuf 不是银弹，但至少能避开 JSON 的反射开销和结构松散问题。
-
json.Marshal对 struct 字段要求首字母大写，小写字段直接被忽略，调试时发现消息为空多半是这原因 - 用
gogoproto插件生成 Go 代码，比官方protoc-gen-go内存占用低 30%，尤其适合高频消息场景 - 千万别把
time.Time直接塞进 protobuf message——它会被转成 int64 时间戳，反序列化时得手动转回time.Time，建议统一用google.protobuf.Timestamp
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
