go与消息队列整合关键在连接复用、通道显式关闭、panic恢复、手动ack控制及context超时防护，否则高并发下会静默丢消息或goroutine阻塞。
Go 与消息队列整合不是“连上就能用”，关键在连接生命周期、错误传播路径和并发模型对齐——否则高并发下会 silently 丢消息或夯住 goroutine。
amqp.Dial 连接泄漏的典型表现与修复
用 amqp.Dial 每次发消息都新建连接，跑几天后 RabbitMQ 出现大量 NOT_FOUND - no exchange 'amq.default' 或连接数爆满，本质是 TCP 连接未释放。
- 必须复用单个
*amqp.Connection实例，全局初始化一次（如用 sync.Once） - 每个消费者/生产者操作应使用独立
*amqp.Channel，且需显式ch.Close()（不能只 defer conn.Close()） - 连接断开时，
conn.NotifyClose()会触发，此时要重建 conn + 重声明队列，而不是静默忽略
消费者 panic 导致消息无限重复消费
用 ch.Consume 启动 goroutine 处理消息时，若业务逻辑 panic，channel 会关闭，但 RabbitMQ 因未收到 ack 会持续重投——表现为同一条消息反复出现在日志里。
- 所有
msgs循环体内必须包一层defer func(){ recover() }() - 手动 ack 要放在处理成功后，且确保
msg.Ack(false)的multiple=false（避免误 ack 前面未处理的消息） - 临时失败（如 DB timeout）建议
msg.Nack(false, true)重新入队；永久失败（如 JSON 解析失败）应发往死信交换机（DLX），而非原路重试
sarama 同步生产者性能卡在 200 msg/s？检查这些配置
默认 sarama.SyncProducer 吞吐极低，不是 Kafka 问题，而是客户端参数未调优。
-
config.Producer.RequiredAcks = sarama.WaitForAll→ 改为sarama.NoResponse或sarama.WaitForLocal，降低等待开销 -
config.Producer.Flush.Frequency = 10 * time.Millisecond→ 缩短批量发送间隔 -
config.Net.DialTimeout = 5 * time.Second和config.Net.ReadTimeout = 10 * time.Second必须显式设小，否则网络抖动时阻塞整个 producer - 不要用同步 producer 做高吞吐场景，改用
AsyncProducer+Successes()channel 捕获结果
Go channel 模拟队列只能用于单元测试
有人用 chan []byte 自实现“轻量队列”，上线后发现消息堆积不告警、无持久化、无法横向扩展——它只是 goroutine 协作机制，不是消息队列。
- 仅限本地调试或压测 mock：比如验证 consumer 逻辑是否 panic，或测重试间隔
- 真实环境必须走 AMQP/Kafka/NATS 等有服务端的中间件，它们提供确认机制、堆积监控、跨进程投递
- 若真想轻量，选 NSQ（单机部署简单）或 NATS JetStream（内建持久化），别自己造轮子
最常被跳过的一步：没给消费者加 context.WithTimeout。哪怕业务逻辑卡死，也要让 goroutine 在 30 秒后强制退出并 nack，否则整条消费链就挂住了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
