ThinkPHP中RabbitMQ消息不丢失需三段式保障：生产者开启confirm模式并处理ack/nack回调；Broker端队列、交换器、消息均设持久化（durable=true且delivery_mode=2）；消费者禁用autoAck，手动调用basic_ack/basic_nack并捕获异常重试。
ThinkPHP 中 RabbitMQ 消息不丢失，核心不在框架本身，而在 AMQP 协议层的三段式保障：生产者确认、Broker 持久化、消费者手动 ACK。ThinkPHP 作为上层应用，只负责正确调用 PHP-AMQP 扩展并配置好行为逻辑。
生产者必须开启 confirm 模式并处理 nack
ThinkPHP 里没有内置的 RabbitTemplate，你得直接用 php-amqplib 库，并手动管理 channel 的 confirm 状态。事务（txSelect）虽可用，但会阻塞、吞吐暴跌，线上严禁使用。
- 调用
$channel->confirm_select()启用 confirm 模式，之后每条消息都会被分配一个递增的delivery_tag - 发送后不能“发完就忘”，必须注册回调：
$channel->set_ack_handler()和$channel->set_nack_handler() -
nack回调里别只打日志——要落库（比如写入mq_failed_log表），带message_id、payload、cause、重试次数，再交由定时任务重推 - 注意：
confirm_select是 channel 级别，每个 channel 只能有一个生效的 confirm 流程，别在循环里反复调用
队列、交换器、消息三者都得设为持久化
光生产者确认没用，Broker 一崩全白搭。ThinkPHP 发送时传参只是表象，真正起作用的是声明阶段的 durable=true 和发送时的 delivery_mode=2。
- 声明队列时必须显式传
['durable' => true]，例如：$channel->queue_declare('order_queue', false, true, false, false)；默认false，不写等于丢命 - 声明交换器也要
durable=true（Direct/Topic/Fanout 默认都是false） - 发消息时，
AMQPMessage构造必须加'delivery_mode' => 2，否则哪怕队列持久，消息仍只存内存 - 镜像队列不是可选项——单节点部署时，哪怕开了持久化，硬盘故障照样丢数据；集群下必须配
ha-mode=all或按策略镜像
消费者必须禁用 autoAck 并手动调用 ack/nack
ThinkPHP 的消费者常写成命令行脚本（如 php think rabbit:consume），最容易犯的错就是忘了关 autoAck。一旦开它，消息取出即删，崩溃=丢失。
立即学习“PHP免费学习笔记（深入）”；
- 调用
$channel->basic_consume()时，第 5 个参数$no_ack必须为false - 业务逻辑包裹在 try/catch 内：成功处理完才调
$channel->basic_ack($delivery_tag)；异常则调$channel->basic_nack($delivery_tag, false, true)（拒绝并重回队首） - 别在消费逻辑里做耗时操作（如远程 HTTP 请求、大文件写入），超时会导致连接中断，RabbitMQ 会误判为消费者挂了而重发；应拆出异步任务或加超时控制
- 如果业务要求幂等，建议在消息体里带
message_id（UUID），消费前先查 Redis 或 DB 是否已处理过该 ID
必须补上 return callback 处理路由失败
Confirm 只管“发到队列”，不管“能不能路由”。若 exchange 找不到绑定 queue，消息会被静默丢弃——这不属于 nack，而是 return 场景，ThinkPHP 里极易漏掉。
- 发送前调用
$channel->set_return_callback()，传一个闭包处理未路由消息 - 典型原因：队列还没声明、binding 错误、routing key 拼写错误、exchange 类型不匹配（比如用 direct exchange 发 topic routing key）
- 回调里至少要做两件事：记录完整
AMQPMessage和reply_code/reply_text到日志；触发告警（如调用钉钉 Webhook） - 配置项
mandatory=true要配合使用，否则消息直接被 broker 丢弃，连 return 都不会触发
最易被忽略的点是：ThinkPHP 自带的队列驱动（如 database、redis）和 RabbitMQ 完全无关，别指望 think-queue 包自动帮你做 confirm 或持久化——它只是个调度壳，底层 AMQP 行为全得你自己用 php-amqplib 控制。每一个 basic_publish、queue_declare、basic_consume 调用，都要对着 AMQP 协议文档核对参数含义，而不是依赖框架封装的“简化接口”。
