根本原因是默认配置锁死网络行为：requiredacks=-1 且 min.insync.replicas>1 导致单节点 kafka 消息卡住；需调小 requiredacks、设 min.insync.replicas=1、配 writetimeout 和批量参数。
用 github.com/segmentio/kafka-go 做生产者时，为什么消息总卡住不发？
根本原因不是代码写错了，而是默认配置把网络行为锁死了。它默认开启 RequiredAcks: -1（等所有副本确认），但如果你本地只跑单节点 Kafka，且没配 min.insync.replicas=1，就会一直等、一直超时。
- 发消息前务必检查 Kafka broker 的
server.properties：确保min.insync.replicas≤ 当前可用副本数（单机调试直接设为1） - 客户端显式设置
RequiredAcks: kafka.RequiredAcks(1)，避免依赖 broker 默认值 - 别忽略
WriteTimeout—— 默认是 10 秒，高并发下容易堆积；建议设为5s并配合重试逻辑 - 批量发送时，
BatchSize和BatchBytes要对齐业务吞吐：太小 → 频繁 flush；太大 → 内存占用高 + 延迟毛刺
消费者组重启后重复消费，kafka.NewReader 怎么正确管理 offset？
不是 offset 没提交，而是提交时机和策略没对上。默认 ReadLagInterval 是 0，意味着不主动拉 lag；而 CommitInterval 默认关闭，全靠手动 CommitOffsets，一漏就丢进度。
- 必须启用自动提交：
CommitInterval: 1 * time.Second，哪怕只是开发环境 - 不要在
ReadMessage后立刻CommitOffsets—— 这会把未处理完的消息也标记为已消费；应在业务逻辑成功执行后再 commit - 消费者启动时，
StartOffset设为kafka.LastOffset（默认）适合大多数场景；若需从头重放，改用kafka.FirstOffset，但得先Seek再ReadMessage - 注意
GroupID必须全局唯一且稳定 —— 改名等于新建消费者组，老 offset 就失效了
用 redis.Streams 替代 Kafka 做轻量级 MQ，哪些地方最容易崩？
Redis Stream 看似简单，但 Go 客户端（比如 github.com/go-redis/redis/v9）的 XADD/XREADGROUP 组合，在并发和错误恢复上很敏感。
-
XREADGROUP不带COUNT参数时，一次只返回一条 —— 高频场景下性能断崖下跌；务必加COUNT 10或更高 - 消费者组首次创建必须用
XGROUP CREATE ... $（$表示从最新开始），否则XREADGROUP返回空；Go SDK 不自动帮你建，得自己client.Do(ctx, "XGROUP", "CREATE", ...) - 消息处理失败时，别直接
ACK—— 应该用XCLAIM把 pending 消息捞回来重试，否则就丢了 - Redis 内存水位要盯紧：
STREAM不自动过期，得靠MAXLEN ~或定时XTRIM，否则 OOM 是早晚的事
微服务间异步调用，怎么让 context.Context 真正穿透到 MQ 消费侧？
不能靠传参塞进消息体里再反序列化 —— 这既破坏类型安全，又绕过 Go 的 context 生命周期管理。真正可行的是把 traceID、deadline、cancel 信号拆解后透传。
立即学习“go语言免费学习笔记（深入）”；
- 发送端：用
ctx.Value("trace_id")提取 trace ID，作为消息 header（kafka.Message.Headers或 Redis Streammap[string]interface{}字段） - 消费端：收到消息后，用 header 构造新
context.WithValue，并根据原始 deadline 设置context.WithTimeout - 取消信号无法跨进程传递，所以不要指望消费端能响应上游 cancel；但可以用 header 带个
ttl_seconds，超时直接 skip 处理 - 别在 consumer goroutine 里直接用原始
ctx—— 它可能早已 cancel，导致日志、metric、HTTP client 全部异常
事情说清了就结束。MQ 集成最难的从来不是连上，而是错峰、背压、上下文延续这些看不见的链路细节。
