Python 使用 Pika 库怎么开启生产者确认机制（Confirm_delivery）并处理失败？

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 3.14.3

微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 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 无法关联到原始业务上下文。