thinkphp异常需原样向上throw，禁用静默捕获；通过x-trace-id串联链路；日志须输出gettraceasstring()；api响应在debug模式下显式返回堆栈，生产环境返回trace_id+错误码。
ThinkPHP接口调用链路里，异常怎么透传到最外层
默认情况下，ThinkPHP 的 catch 会吃掉底层抛出的异常，尤其在封装了 HTTP 客户端（比如 think\Http 或第三方 GuzzleHttp\Client）做服务间调用时，原始错误堆栈、状态码、响应体全被截断，只剩一个模糊的 Exception。这不是框架 bug，是默认行为设计使然。
关键点在于：异常必须原样向上 throw，不能只 log 后吞掉；同时要确保中间件、事件、Hook 不做静默捕获。
- 检查所有自定义中间件中是否写了
try...catch却没 re-throw，尤其是日志/监控类中间件 - 禁用
app_debug = false下的「友好错误页」干扰：它会把真实异常替换成HttpException，掩盖原始错误类型 - 若用了
think\facade\Http，注意它默认不抛异常，需手动加->fail(false)或检查->getStatusCode()
用 trace_id 关联多层服务异常日志
单纯让异常冒泡还不够——你得知道这个 InvalidArgumentException 是从订单服务的第 3 次重试里来的，还是从用户服务的缓存穿透触发的。ThinkPHP 本身不内置分布式 trace，但可以轻量接入。
核心思路是：入口请求带 X-Trace-ID，每发起一次下游 HTTP 调用，都把当前 trace_id 注入 header，并在日志中固定输出。这样 ELK 或 Grafana 就能串起整条链路。
- 在全局中间件中读取或生成
trace_id，存入think\Container或静态属性，避免每次 new 实例重复生成 - 调用下游服务时，统一通过封装函数（如
remoteCall()）注入['headers' => ['X-Trace-ID' => $id]] - Log 配置里启用
format，把{trace_id}插入日志模板，否则日志里看不到上下文关联
ThinkPHP 日志里看不到完整异常堆栈
常见现象：日志只记了 SQLSTATE[HY000]: General error，但没显示哪行代码、哪个模型、哪个事务导致的。这是因为 ThinkPHP 默认日志处理器对 Throwable 处理太粗粒度。
根本原因在于 think\log\driver\File 对异常对象只调用了 __toString()，而没调用 getTraceAsString()。修复不靠换驱动，靠改写法。
- 不要直接
Log::error($e)，改用Log::error($e->getMessage() . "\n" . $e->getTraceAsString()) - 若用了 monolog，确认 handler 配置没开启
ignore_exceptions或设置了过短的max_trace_length - 数据库异常特别容易丢上下文：在
Db::listen()回调里捕获PDOException并主动打日志，别等框架兜底
可视化链路时，前端看不到后端异常详情
浏览器控制台只看到 500 Internal Server Error，但接口返回体是空的，或者只有 {"code":500,"msg":"服务器错误"} —— 这不是安全考虑，是开发期过度屏蔽了调试信息。
ThinkPHP 的 json 响应默认不包含异常细节，即使 app_debug=true，也要显式允许。
- 在异常处理类（如
app\common\exception\Handler）的render()方法中，判断是否为 API 请求，再决定是否输出$e->getTraceAsString() - 禁止在生产环境返回完整堆栈，但可返回
trace_id+ 精简错误码（如"ERR_USER_NOT_FOUND"），前端按码查文档 - 注意 Nginx 或 CDN 可能缓存了 500 响应体，导致前端看到的永远是旧错误，加
Cache-Control: no-store头防坑
链路可视化真正的难点不在埋点，而在每个环节是否“敢放”和“能放”原始错误。很多团队卡在权限意识和日志规范上，而不是技术实现。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
