channel.confirm_delivery() 必须在声明队列之后调用，因为该方法需 channel 进入“可发布”状态才生效，而声明队列会触发 channel 初始化与状态同步；提前调用则消息不被确认且无报错。
为什么 channel.confirm_delivery() 必须在声明队列之后调用？
因为 RabbitMQ 的确认模式（publisher confirms）是 channel 级别的协议特性，且必须在 channel 进入“可发布”状态后启用——而声明队列（channel.queue_declare()）或交换器会触发 channel 的初始化和状态同步。如果在 channel.basic_publish() 之前没调用 channel.confirm_delivery()，后续发出去的消息**不会被确认**，也不会触发回调，但代码不会报错，容易误以为成功了。
常见错误写法：channel.confirm_delivery() 放在连接建立后、但还没声明任何资源之前；或者放在 basic_publish() 之后。
- 正确顺序：建立连接 → 创建 channel → 声明 exchange/queue → 立即 调用
channel.confirm_delivery()→ 发布消息 - 注意：不能对同一个 channel 多次调用，第二次会抛
ChannelClosedByBroker - 该调用底层发送
confirm.select协议帧，RabbitMQ 返回确认后 channel 才进入 confirm 模式
怎么注册 on_return_callback 捕获路由失败？
on_return_callback 是处理「消息无法路由」的唯一途径，比如 routing key 错误、队列不存在、mandatory=true 但无匹配队列等情况。它和 confirm 机制互补：confirm 回调只管「是否被 broker 接收」，而 on_return_callback 管「是否被成功路由到队列」。
必须配合 mandatory=True 使用，否则 broker 直接静默丢弃未路由消息，根本不会触发回调。
立即学习“Python免费学习笔记（深入）”；
- 注册方式：
channel.add_on_return_callback(on_return_callback)，必须在confirm_delivery()之后、basic_publish()之前 -
on_return_callback函数签名固定为：def on_return_callback(channel, method, properties, body): - 典型错误：忘记设
mandatory=True，或把 callback 注册在 publish 之后
如何用 publish() 的 callback 和异常捕获组合判断失败？
Pika 本身不提供 publish 成功/失败的同步返回值，必须靠异步回调 + 主动异常防御。核心逻辑是：先检查网络和 channel 状态（避免调用时已断连），再发消息，然后依赖两个回调分支覆盖全部失败路径。
- 网络层失败（如连接中断）：会在
basic_publish()调用时直接抛ChannelClosed或ConnectionClosed，需 try/catch - broker 接收失败（如内存满）：触发
on_return_callback（mandatory=True 时）或 confirm 回调中的delivery_tag未被确认 - 真正可靠的失败感知：监听 confirm 回调里的
delivery_tag是否超时未收到 ack/nack —— Pika 不自带超时，得自己用delivery_tag做 map 记录 + 启动定时器清理 - 示例片段：
def on_delivery_confirmation(channel, method, properties, body): if method.NAME == 'Basic.Ack': # 成功 pass elif method.NAME == 'Basic.Nack': # 持久化失败或 broker 内部错误 pass
为什么不能只依赖 on_return_callback 就认为消息安全？
因为 on_return_callback 只捕获「路由失败」，而消息可能被 broker 接收并成功路由，随后因磁盘满、策略拒绝、队列达到 max-length 而被丢弃——这类问题只有 confirm 回调里的 Nack 能反映。更关键的是：RabbitMQ 默认开启 publisher_confirms，但若队列是 transient（非 durable）、消息 delivery_mode=1，Nack 可能不会触发（broker 认为丢弃可接受）。
- 确保可靠性：队列声明时加
durable=True，消息发时设properties=pika.BasicProperties(delivery_mode=2) - 不要省略
on_return_callback，但它只是第一道防线；confirm 回调才是最终仲裁者 - 生产环境务必监控
unacked消息数，长期堆积说明 confirm 回调没被正确消费或处理阻塞
确认机制不是开个开关就完事，confirm_delivery() 的时机、mandatory 的配合、delivery_mode 与队列 durable 的一致性，三者缺一不可。最容易漏掉的是：发完消息后不维护 delivery_tag 生命周期，导致 nack 无法关联到原始业务上下文。
