位移管理决定消息是否重复或丢失：Kafka需显式提交Offset以防重启重消费或丢/重消息；RabbitMQ靠msg.Ack()隐式推进delivery tag；Redis List需消费端自行维护游标并确保消息ID唯一及死信处理。
位移管理不是“记个数”那么简单，它直接决定消息是否重复或丢失——Kafka 必须用 Offset 提交，RabbitMQ 靠 msg.Ack() 隐式推进，Redis List 则靠消费端自己维护游标。
为什么 Kafka 消费者必须显式提交 Offset
Kafka 的 ConsumerGroup 不会自动帮你“记住”当前消费到哪。不提交，重启后就从 OffsetNewest 或 OffsetOldest 重新开始；提交太早（比如刚收到就 commit），处理失败时就会丢消息；提交太晚（比如等 DB 写完再 commit），崩溃会导致重复消费。
-
config.Consumer.Offsets.AutoCommit.Enable = false：必须关掉自动提交，否则无法控制精度 - 推荐在业务逻辑成功后、
msg.MarkOffset()或consumer.CommitOffsets()手动提交，且要检查返回 err - 别用
sarama.OffsetOldest启动后就不管 offset：它只是起点，后续必须靠MarkOffset()持续更新 - 如果消费者运行时间长，记得定期调
consumer.CommitOffsets()，避免单次提交数据量过大超时
RabbitMQ 的位移其实是 Ack 状态机
RabbitMQ 没有“offset”概念，它的位移由 broker 维护的 delivery tag 和 channel 上的 unacknowledged 消息集合共同决定。你每调一次 msg.Ack()，broker 就把对应 delivery tag 从 unack 集合里删掉——这就是位移推进。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
ch.Consume(..., autoAck=false, ...)是前提，autoAck=true 相当于“位移永远在最前”，消息一发就丢 - 必须确保每条
amqp.Delivery只被Ack()或Nack()一次；重复调用会报channel error: not found，之后所有操作卡住 - panic 场景下，recover 后应立即
msg.Nack(true, false)，否则该 delivery tag 卡死，后续消息全堵住 - 不要跨 goroutine 传
msg却漏传ch：ACK 必须在创建它的同一个amqp.Channel上执行
Redis List 队列怎么安全维护“伪位移”
Redis 本身不记录消费位置，BRPop 每次弹出一个值后就从 list 删掉了——所以“位移”只能靠你自己的状态来体现：要么记最后成功处理的 message ID，要么用另一个 key 存 cursor。
- 别依赖
LRANGE查剩余长度判断进度：并发消费者下不准，且没意义——List 是 FIFO，删了就是删了 - 如果需要重放或断点续传，消息体里必须带唯一
id字段，并写入 Redis 的SET或Sorted Set做已处理记录 - 延时任务用
ZSet时，位移管理变成“score 小于 now 的消息已迁移并标记为已消费”，迁移脚本必须用 Lua 保证原子性 - JSON 解析失败不能跳过：得把原始
result[1]存进死信 key，否则这条消息彻底消失，连 trace 都没有
真正难的不是“怎么记”，而是“什么时候记”——Kafka 提交时机错半秒可能丢数据，RabbitMQ 的 Nack 参数选错会让消息进黑洞，Redis 里少一个 if err != nil 就可能让整条链路静默失败。这些细节不堆在一起压测，根本看不出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
