ThinkPHP如何做接口调用链路异常根因定位_ThinkPHP快速识别故障源头服务【指南】-ThinkPHP-PHP中文网

ThinkPHP trace日志不显示下游服务报错，因默认只记录本应用内流程，不捕获外部HTTP请求的响应与错误；需手动捕获异常并记录响应详情。

thinkphp如何做接口调用链路异常根因定位_thinkphp快速识别故障源头服务【指南】

因为默认的trace只记录本应用内的执行流程，不捕获curl_exec、file_get_contents或GuzzleHttp\Client等发起的外部请求响应体和错误码。你看到的“500”，很可能是本层抛出的Exception，而非下游真实返回。

实操建议：

在发起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头到下游请求中

ThinkPHP本身不自动传递上下文ID，Log::debug('xxx')打出来的日志是孤立的，查问题时根本串不起来。

实操建议：

在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()内部抛出异常后，如果没被外层catch住，框架会静默吞掉部分上下文，导致你只看到PDOException: SQLSTATE[40001]，却不知道哪条update触发了死锁。

实操建议：

所有事务块必须包在try/catch里，catch中立即记录Db::getLastSql()和$e->getTraceAsString()
开启db.debug => true后，日志里会出现SQL: UPDATE ...行，但仅限成功执行的SQL；失败SQL得靠Db::getRealSql()在执行前预取
避免在事务中调用curl或Redis::set()，网络延迟可能拉长锁持有时间，且这类操作不会出现在DB日志里

关掉调试模式后，dump()失效，exception日志里只有消息和堆栈，没有$user、$params这些关键变量值，定位像盲人摸象。

实操建议：

在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，否则日志审计过不了