链路ID应在入口统一生成32位字符串（如req_时间戳_微秒_随机hex），并通过X-Request-ID头透传下游、注入日志上下文、显式携带至队列任务，避免因并发、进程隔离或框架限制导致丢失。
PHP 请求链路 ID 怎么生成才不重复又可追溯
用 uniqid('', true) 或 random_bytes(16) 都行，但别用 time() 或 mt_rand() 单独拼接 —— 并发高时大概率撞车，日志里看着像同一个请求，实际是多个。
推荐方案：在入口（如 API 网关、前端控制器）统一生成一个 32 位字符串 ID，格式为 req_ 开头 + 时间戳 + 微秒 + 随机字节的 hex 表示，比如 req_1715829345_123456_ab3f...。这样既带时间序，又靠随机性防冲突。
- 别在每个函数里重新生成，否则下游服务拿到的 ID 就断了
- 如果用 Swoole 或 Hyperf，注意协程间不能共用全局变量存 ID，得用
Co::getContext()或ApplicationContext::getContainer()->get(ContextInterface::class) - Apache + PHP-FPM 场景下，
$_SERVER['REQUEST_ID']可能已被 mod_unique_id 设置，但不可靠 —— 它不跨 HTTP 跳转，也不透传到 cURL 后端
怎么把链路 ID 透传到下游 HTTP 请求
cURL 发起调用时，必须手动把当前链路 ID 塞进请求头，下游服务才能接着用。光写日志没用，ID 断在第一跳就全废了。
关键动作就两步：读取、透传。别依赖框架自动注入 —— 大部分轻量框架（如 Slim、Lumen）根本不处理这个。
立即学习“PHP免费学习笔记（深入）”；
- 读取来源优先级：HTTP 请求头
X-Request-ID> 自己生成的新 ID - cURL 发起前务必设置：
curl_setopt($ch, CURLOPT_HTTPHEADER, ['X-Request-ID: ' . $requestId]) - 用 Guzzle 时，别只写
headers => [...]，要确保每次 new Client 都没复用旧连接导致 header 残留；更稳妥的是在on_stats或中间件里统一加 - 如果下游是 Go/Java 服务，注意它们默认不记录
X-Request-ID，得自己写日志格式把该字段捞出来，否则你传了也白传
日志里怎么稳定输出链路 ID
不是所有日志组件都支持动态上下文。Monolog 1.x 默认不携带 request ID，2.x 虽有 Processors，但得手动绑定，且容易漏掉异步任务（如队列消费、定时脚本）。
最省事的方式：在日志 handler 初始化时，把当前链路 ID 注入为固定 context 字段，而不是每次 info() 都临时传。
- 用 Monolog：注册
WebProcessor不够，它只抓 $_SERVER，得自己写个RequestIdProcessor，从全局变量或上下文取$requestId - 如果用了 PSR-3 兼容 logger，确保
LoggerInterface::withContext()被正确调用 —— 很多封装层会忽略这个方法，直接丢弃 context - 错误日志（
error_log()或trigger_error()）完全不走 logger 流程，必须提前在set_error_handler里补上 ID，否则 500 错误日志里看不到链路线索
为什么队列任务和异步回调里链路 ID 经常丢失
因为队列消费是新进程/新协程启动的，HTTP 上下文彻底清空。你传进去的 job 数据里没显式带上 request_id，它就永远找不回来了。
不是加个全局变量就能解决 —— 进程隔离决定了父进程设的 $GLOBALS['req_id'] 在子进程里根本不存在。
- 投递队列时，必须把当前
$requestId作为字段写进 job payload，例如['user_id' => 123, 'trace_id' => 'req_...'] - Redis 队列用
LPUSH存 JSON，别用SET存裸字符串，否则反序列化后 ID 可能被截断或编码错乱 - Supervisor 启动的 worker 进程，不要用
php artisan queue:work --daemon（已废弃），它会复用内存导致上下文污染；改用--once模式，每次 job 都是干净环境
链路 ID 的核心不在“生成”，而在“不丢”。只要一次透传失败、一次日志漏打、一次队列没携带，整条链就断成两截 —— 查问题时你永远不知道那个 500 是来自 A 接口还是 B 接口的子调用。
