ThinkPHP trace日志不显示下游服务报错，因默认只记录本应用内流程，不捕获外部HTTP请求的响应与错误；需手动捕获异常并记录响应详情。
ThinkPHP接口调用链路里，trace日志为什么总看不到下游服务报错？
因为默认的trace只记录本应用内的执行流程，不捕获curl_exec、file_get_contents或GuzzleHttp\Client等发起的外部请求响应体和错误码。你看到的“500”，很可能是本层抛出的Exception，而非下游真实返回。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在发起HTTP调用前，统一用
try/catch包裹，并手动把$e->getMessage()、$response->getStatusCode()、$response->getBody()->getContents()写入Log::error()，别依赖trace - 若用
GuzzleHttp\Client，务必设置http_errors => false，否则4xx/5xx会直接抛异常，拿不到原始响应 - ThinkPHP 6.1+ 可配合
think-swoole启用coroutine context透传trace_id，但需手动注入X-Request-ID头到下游请求中
如何让Log::debug()里的调用链ID贯穿整个接口？
ThinkPHP本身不自动传递上下文ID，Log::debug('xxx')打出来的日志是孤立的，查问题时根本串不起来。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/middleware/TraceId.php中间件中生成$traceId = uniqid('t_', true)，存入Container::getInstance()->bind('trace_id', $traceId) - 自定义一个
TracedLogger类，重写write方法，在每条日志开头拼上[{$this->traceId}] - 调用下游服务时，必须显式带上
headers => ['X-Trace-ID' => $traceId]，否则链路断在第一跳
Db::transaction()嵌套失败时，为什么根因日志里找不到SQL回滚记录？
事务回滚本身不记日志，Db::transaction()内部抛出异常后，如果没被外层catch住，框架会静默吞掉部分上下文，导致你只看到PDOException: SQLSTATE[40001]，却不知道哪条update触发了死锁。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有事务块必须包在
try/catch里，catch中立即记录Db::getLastSql()和$e->getTraceAsString() - 开启
db.debug => true后，日志里会出现SQL: UPDATE ...行，但仅限成功执行的SQL；失败SQL得靠Db::getRealSql()在执行前预取 - 避免在事务中调用
curl或Redis::set()，网络延迟可能拉长锁持有时间，且这类操作不会出现在DB日志里
线上环境app_debug => false，怎么快速拿到异常发生时的完整变量快照？
关掉调试模式后，dump()失效，exception日志里只有消息和堆栈，没有$user、$params这些关键变量值，定位像盲人摸象。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/exception/Handle.php的report方法里，对$exception做getTrace()遍历，遇到args字段就json_encode($arg, JSON_UNESCAPED_UNICODE | JSON_PARTIAL_OUTPUT_ON_ERROR)后写入日志 - 禁用
var_dump类函数，改用think\helper\Debug::dump()（TP6.2+），它在app_debug=false下仍可输出到runtime/log/文件 - 敏感字段如
password、token要提前从$vars中unset，否则日志审计过不了
链路越长，上下文丢失越快；不是所有throw new Exception都会带上足够线索，得自己补全。
