php消费者必须关闭auto_ack才能真正控制消息确认：需将basic_consume第四个参数设为false，显式调用basic_ack或basic_nack，配合队列持久化、消息delivery_mode=2及basic_qos限流，三者缺一不可。
PHP消费者必须关闭auto_ack才能真正控制消息确认
默认开启的auto_ack会让RabbitMQ在投递消息后立刻认为已消费成功，一旦消费者崩溃或处理中途失败，这条消息就永久丢失——这和“异步任务不丢不重”的基本目标直接冲突。所以第一步就是把basic_consume的第四个参数设为false：
$channel->basic_consume('task_queue', '', false, false, false, false, $callback);
注意：这个false不是可选优化项，是可靠性前提。没关它，后面所有幂等、重试、死信配置都白搭。
手动调用basic_ack()前必须确保业务逻辑100%完成
ACK不是“收到就点”，而是“做完才点”。常见错误是把$msg->ack()写在回调开头、或夹在日志打印之后但还没入库/调用外部API之前。一旦这时进程被kill，消息就卡在unacked状态，既不重试也不进DLQ。
- 正确姿势：所有数据库写入、Redis校验、第三方HTTP请求全部返回且成功后，再执行
$channel->basic_ack($msg->getDeliveryTag()) - 别依赖
$msg->ack()快捷方法——它隐式使用当前$channel，而实际生产中常有多个channel混用，容易出错 - 如果业务逻辑抛异常，必须捕获并显式拒绝：
$channel->basic_nack($msg->getDeliveryTag(), false, true)（重入队）或false（丢弃）
消息持久化 + 队列持久化 + 手动ACK三者缺一不可
只做其中一两个，依然会丢消息。比如：
- 开了
queue_declare(..., true, ...)但没设delivery_mode => 2→ RabbitMQ重启后消息消失 - 设了
delivery_mode => 2但没关auto_ack→ 消费者崩了，消息直接从内存蒸发 - 全做了，但没配
basic_qos(null, 1, null)→ 一个慢消费者积压几百条unacked消息，其他worker干瞪眼
完整声明队列+消息的最小安全组合是：
$channel->queue_declare('task_queue', false, true, false, false);
$msg = new AMQPMessage($data, ['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT]);
死信队列（DLQ）不是兜底，而是告警入口
很多人以为配了x-dead-letter-exchange就万事大吉，其实不然。DLQ本身不会自动重试或修复，它只是把失败消息“隔离”出来。真正起作用的是后续动作：
- 必须给队列设置
x-message-ttl或用basic_nack带requeue=false触发转移 - DLQ队列本身也要声明为
durable=true，否则RabbitMQ重启后DLQ清空，故障记录彻底丢失 - 监控脚本不能只查DLQ长度，得解析每条消息的
application_headers里的重试次数、原始路由键、失败原因字段
最容易被忽略的一点：消费者进程崩溃时，未ack消息会自动重回队列——但前提是它没被basic_qos锁死在某个channel里。这点在多worker部署时尤其关键。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
