必须用think\facade\Log配合自定义日志处理器注入TraceID，否则跨请求、协程、中间件时链路ID会丢失；需在应用初始化阶段注册上下文透传处理器，并通过Log::setConfig注入格式化模板，Swoole下须用Co::getContext()或Container协程隔离容器。
ThinkPHP 接口调用链路日志怎么打才不丢上下文
直接结论：不用 Log::write() 原始写法，必须用 think\facade\Log + 自定义日志处理器注入 TraceID，否则跨请求、跨协程、跨中间件时链路 ID 会断。
常见错误是每个接口里手动拼 trace_id 字段塞进日志，结果发现异步任务、队列消费、Redis 回调里全没这个 ID —— 因为 ThinkPHP 默认的 Log facade 是 request 生命周期绑定的，中间件一结束、worker 一重启，上下文就丢了。
- 必须在应用初始化阶段（如
app/common.php或服务提供者中）注册一个带上下文透传的日志处理器，比如继承think\log\driver\File并重写write()方法，从think\Request或think\facade\Session（如果用了 session）或更可靠的think\helper\Str::uuid()生成/复用 trace_id - 推荐把 trace_id 存到
think\Container::getInstance()->get('request')->header('x-trace-id', Str::uuid())，再通过Log::setConfig(['format' => '[{date}] [{level}] {trace_id} {message}'])注入格式化模板 - 注意：Swoole 模式下不能依赖
$_SERVER或全局变量存 trace_id，必须走Co::getContext()或Container的协程隔离容器
如何让 ThinkPHP 日志自动带上调用来源（API 路由 + 方法名）
默认日志只记时间、级别、消息，查问题时根本不知道这行日志来自哪个控制器哪个方法。靠人工 grep 路由配置和控制器太慢，也容易漏。
关键不是改日志内容，而是改日志上下文注入点。ThinkPHP 6.1+ 支持在 Log::record() 时传第二个参数作为上下文数组，但多数人没意识到这个参数能被日志处理器捕获并格式化输出。
立即学习“PHP免费学习笔记（深入）”；
- 在基础控制器的
initialize()方法里统一写：Log::record('enter ' . $this->request->action(), 'info', ['route' => $this->request->url(), 'controller' => get_class($this), 'action' => $this->request->action()]); - 自定义日志驱动中，在
write()方法里检查$data['context']是否存在route或controller键，有则拼进日志行；否则 fallback 到debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2)抽 controller/action（仅开发环境启用，避免性能损耗） - 别用
__METHOD__或__FUNCTION__直接打，它们在中间件或事件回调里指向的是框架内部方法，不是业务入口
分布式环境下 ThinkPHP 日志聚合为什么搜不到跨服务调用记录
因为默认日志是本地文件，而你调用的下游服务（如 Python 微服务、Node.js 网关）压根不走你的 runtime/log/ 目录。所谓“聚合”，不是把所有日志 cp 到一台机器，而是统一打到支持 trace_id 关联的中心存储（如 ELK、Loki、Datadog）。
ThinkPHP 本身不内置日志上报能力，得自己补一层。重点不是“怎么发”，而是“发什么”——必须确保每条日志都含可关联字段：trace_id、span_id、parent_span_id、service_name、host、timestamp。
- 用
think\log\driver\Socket驱动（非官方，需自己实现）或替换为monolog/monolog+elasticsearch/elasticsearch客户端，但注意 Monolog 的Processors要挂载 trace_id 注入逻辑 - 不要在日志里硬编码
service_name，应从配置读：config('app.service_name', 'tp-api')，方便不同部署环境区分 - 警惕 Swoole 下的连接复用：Socket 日志驱动若没做连接池或超时控制，高并发时会卡住整个 worker 进程
为什么加了链路日志后 ThinkPHP 接口响应变慢了 200ms+
不是日志本身慢，是日志写入阻塞了主流程。尤其用了同步 HTTP 上报、文件锁冲突、或在循环里高频调用 Log::info()。
最典型的坑：在 foreach 处理 1000 条数据时，每条都 Log::info('process item', ['id' => $id]) —— 这等于触发 1000 次磁盘 I/O 或网络请求，而不是一次批量写入。
- 高频日志必须异步：用
think\queue\Job包一层日志写入任务，或借助 Swoole 的Co::create()启协程非阻塞发送（注意协程安全） - 文件驱动下开启
realtime_write => false（TP6.2+ 支持），让日志先缓存在内存，定时 flush，但要注意进程重启时缓存丢失风险 - 开发环境可开 debug 日志，生产环境务必关闭
app_debug，否则框架会自动记录 SQL、路由匹配等冗余日志，量级翻几倍
链路日志真正的难点不在怎么打，而在怎么保证 trace_id 在所有可能出口（HTTP、RPC、MQ、定时任务）里都不丢、不错、不重复。一旦某个环节漏传，整条链就断成两截，排查时反而更费劲。
