$message->body为null主因是amqp协议帧损坏、broker异常断连、客户端与broker协议不兼容或重连时误读控制帧，属传输层故障而非业务空消息。
为什么 $message->body 会是 null？
不是队列发了空消息，而是 PHP 客户端在底层解析失败或网络异常时，AMQPMessage 对象的 body 属性被初始化为 null，但 $message 本身不为 null。常见于：AMQP 协议帧损坏、Broker 强制断连后残留未完整接收的数据、PHP 扩展（如 php-amqplib）版本与 Broker 协议不兼容（比如用 3.6.x 客户端连 RabbitMQ 4.0+ 的新协议栈）、或消费者在重连过程中误读了控制帧。
收到 null body 时不能直接 json_decode 或 foreach
一旦 $message->body 是 null，任何对它的解包操作都会触发 Warning 或 Fatal Error（如 json_decode(null) 返回 null，但后续 ->order_id 会报 Trying to get property 'order_id' of non-object）。防御性检查必须放在业务逻辑最前：
- 显式判断
is_string($message->body) && strlen($message->body) > 0，不能只用!empty($message->body)（因为empty(null)和empty('')都为 true，但处理方式应不同） - 若
$message->body === null，立刻调用$channel->basic_nack($delivery_info['delivery_tag'], $requeue = false)，避免无限重试 - 记录完整上下文：
$delivery_info['delivery_tag']、$message->getHeaders()、当前$channel->getConnection()->getConnectionId()
如何区分「真空消息」和「解析失败」？
真正由上游发来的空消息极少见（除非业务主动发 '' 或 '{}'），绝大多数 null body 是传输层问题。关键判断依据有三个：
-
$message->getReplyCode()不为 0 —— 表示 AMQP 协议层已报错，此时body必为null，应拒绝并告警 -
isset($delivery_info['redelivered']) && $delivery_info['redelivered'] === true且$message->body === null—— 大概率是前序消费者崩溃导致连接异常中断，Broker 重发时帧不全 -
count($message->getHeaders()) === 0且$message->getBody() === null—— 基本可判定非业务消息，跳过业务逻辑，直接 nack
PHP-FPM 或 CLI 长进程下容易忽略的细节
CLI 消费者常驻运行，$message 对象复用或内存残留可能让前一次的 null 状态污染后续循环。必须确保：
- 每次
basic_consume回调内，$message都是全新实例 —— 若你用了对象池或静态缓存，要手动unset($message) - 不要在
catch块外做任何依赖$message->body的操作，包括日志格式化（log('msg: ' . $message->body)会拼出msg:而无报错，掩盖问题） -
register_shutdown_function中若尝试访问$message->body，它大概率已是null或未定义 —— shutdown 时作用域已销毁，该处只做连接清理，不做消息处理
null body，建议主动关闭当前 channel 并重建连接，而不是继续等待下一条“正常”消息。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
