TP6的CLI环境（如RabbitMQ消费端）不触发render()，因exception_handle配置仅对HTTP请求生效；需手动绑定set_exception_handler、register_shutdown_function，并在handle()内try/catch Throwable兜底。
不能。 TP6 的自定义异常处理器 render() 方法在 RabbitMQ 消费端完全不生效——因为消费命令是 CLI 环境运行的，而 CLI 默认绕过 HTTP 请求生命周期，exception_handle 配置项根本不会被加载，更不会触发 render()。
为什么 CLI 消费命令不走全局异常处理器
ThinkPHP6 的 exception_handle 配置只对 HTTP 请求有效；php think consume-order 这类自定义命令属于 CLI 应用，框架启动时默认不初始化完整异常处理链。即使你在 config/app.php 里写了 'exception_handle' => \app\exception\Handler::class，它也不会自动绑定到 CLI 进程中。
- CLI 下
App::getInstance()不会自动注册think\exception\Handle服务 -
render()只在响应生成阶段调用，而消费者是长连接循环，没有“响应”概念 - 未捕获异常直接由 PHP 原生
set_exception_handler()接管，不是你的Handler类
如何让 RabbitMQ 消费者真正捕获所有错误
必须手动接管 CLI 异常和致命错误，不能依赖 HTTP 那套流程。关键动作有三步：
- 在消费者命令类的
handle()开头，显式绑定异常处理器：set_exception_handler([$this, 'handleException']) - 在同一类中定义
handleException()方法，里面调用$this->log()->error()记录，并确保exit(1)终止当前循环（避免消息重复消费） - 补上致命错误兜底：
register_shutdown_function(function () { if ($e = error_get_last()) { /* 记录并 exit */ } })
注意：不要在 handleException() 里调用 response() 或 view() —— CLI 没有响应对象，会报错。
立即学习“PHP免费学习笔记（深入）”；
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
AMQP 消费循环里最容易漏掉的两个错误点
RabbitMQ 消费者不是“跑一次就完”，而是持续拉取消息的长进程。以下错误若没显式处理，会导致静默失败或连接泄漏：
-
PhpAmqpLib\Exception\AMQPTimeoutException：网络抖动或 Broker 忙时常见，不捕获就会中断循环，但进程不退出，表现为“卡住不动” -
AMQPChannelClosedException：信道被 Broker 主动关闭（如超时、权限变更），不重建 channel 就会一直报Channel is closed
正确做法是在 basic_consume() 外层加 try/catch，并在 catch 中做 $channel->close() + $connection->reconnect()，而不是指望全局 handler 自动恢复。
消息体解析失败时，别让异常逃逸出 handle() 方法
TP6 消费者收到的是原生 AMQPMessage 实例，$message->body 是原始字符串。如果业务代码里直接 json_decode($message->body, true)，而消息本身 JSON 格式错误，就会抛 TypeError 或 JsonException。
- 这类异常不属于
\think\exception体系，render()完全收不到 - 必须在
handle()内部用try/catch包住整个业务逻辑，且至少捕获Throwable - 失败时要显式调用
$message->nack()（非 requeue），否则消息会卡在 unacked 状态，堆积后触发Too many unacked messages
最稳妥的结构是：一个外层 try/catch Throwable 负责兜底记录 + nack，内层再按需细分 JsonException、InvalidArgumentException 等做不同处理。
真正难的不是写个 catch，而是想清楚每种异常该不该重试、要不要 nack、是否要发告警——这些决策点都在消费者内部，和 HTTP 异常处理器无关。
