hyperf 3.1 中 amqp 消费需严格遵循 ack/nack 时机、可控重试与业务幂等三者协同：ack 必须在完整业务成功后执行，nack 需结合 retry_count 与死信队列分流异常，幂等须基于唯一业务键+数据库约束+事务保障。
Hyperf 3.1 中使用 AMQP 消费 RabbitMQ 消息时，遇到消费异常必须兼顾三件事：正确控制 ACK/NACK 时机、确保消息重试逻辑可控、彻底规避重复处理——这三者缺一不可。协程环境下尤其要避免在未完成业务前提前 ACK，也不能让失败消息无限堆积或静默丢弃。
手动 ACK 是底线，不是可选项
Hyperf 的 hyperf/amqp 默认启用手动 ACK（需确认配置中 'ack' => true），这是防止消息丢失和误删的基础。关键在于 ACK 必须放在业务逻辑**完全成功之后**，且不能被协程调度打断。
- 不要在 try 块开头就调用
$message->ack()，否则异常发生时消息已被确认，后续无法重试 - 推荐结构：先执行数据库操作、调用下游服务等核心逻辑 → 成功后调用
$message->ack()→ 异常捕获中调用$message->nack(requeue: true)（允许重试）或requeue: false（进入死信） - 注意协程中断风险：若业务中含
co::sleep()或异步 HTTP 调用，需确保整个流程在单个协程内原子完成，避免因超时或调度导致 ACK 状态错乱
重试 + 死信队列构成可靠兜底链路
单纯靠 nack requeue 不足以应对瞬时故障，需配合重试计数与死信路由，把“可恢复异常”和“需人工干预异常”区分开。
- 在消息体 payload 中嵌入
retry_count字段，每次 nack 前递增；消费者启动时检查该值，超过阈值（如 3 次）则nack(requeue: false) - RabbitMQ 需提前为队列配置 DLX（Dead Letter Exchange）和 DLK（Dead Letter Routing Key），例如将
order.created.dlx绑定到dlq.order队列 - 单独部署一个
DlqOrderConsumer，只负责记录日志、发告警、提供人工重放接口，不参与主业务流
幂等性必须由业务层强保障
无论 ACK 多严谨、重试多克制，网络抖动或消费者重启仍可能导致同一条消息被投递多次。此时唯一可靠的防线是幂等设计。
- 每个消费动作绑定唯一业务标识，如订单创建消息用
order_id+event_id作为联合幂等键 - 优先走数据库唯一索引（如
UNIQUE KEY(order_id, event_type)）拦截重复插入；若涉及更新操作，改用INSERT ... ON DUPLICATE KEY UPDATE或乐观锁（version字段） - 避免仅依赖 Redis setnx 做幂等：Redis 故障或过期策略不当会导致漏判；应作为二级校验，而非唯一依据
- 幂等逻辑必须包裹在事务内，且与 ACK 位于同一协程上下文，确保“校验→执行→确认”三步不被拆开
不复杂但容易忽略：ACK、重试、幂等不是三个独立模块，而是一条不可分割的消费生命线。Hyperf 协程加速了执行，也放大了状态不一致的风险——稳住这条线，消息才真正可靠。
