还能对日志，不等于该靠时间戳猜
把「各服务日志时间差不多」当成可以对齐一次请求的理由，往往会在时钟漂移、异步队列与重试场景下对错行：同一秒内多请求混在一起，值班只能靠猜。
更稳妥的默认态度是：入口生成请求 ID，跨服务透传，采样与关联字段齐全。本文只谈通用闸门。
!请求ID三闸：入口生成、跨服务传播、采样关联(assets/request-id-propagation-gate-body-01-2026-08-20.png)
闸门一：入口是否生成稳定请求 ID
入口应生成不可猜测、足够长的请求 ID，并写入日志与响应头（对内）。缺失 ID 的请求不应静默进入关键写路径，否则事后无法回放。
闸门二：是否跨服务传播
网关、应用、消息消费者与异步任务应透传同一 ID 或可映射的父 ID。只在单服务打印、下游另起一套，等于没有跨服务关联。抽检一条跨服务调用，确认同一 ID 出现在全链路关键日志。
!跨服务透传：下游不得另起一套无从关联的 ID(assets/request-id-propagation-gate-body-02-2026-08-20.png)
闸门三：采样与关联是否可核对
高流量下全量详日志可能不可行，但采样策略要写清：错误全采、成功抽样，且采样记录仍带请求 ID。仅有时间戳、没有关联键的对账，不能作为放行标准。
局限、替代路线与复核清单
请求 ID 不能替代完整链路追踪，但能挡住最常见的「靠猜钟」。更完整的替代路线是「请求 ID + 传播约定 + 采样策略 + 可选 Trace」。
发布前至少复核四问：入口是否生成；下游是否透传；错误是否可按 ID 拉齐；是否仍有人只靠时间戳排障。本文描述通用模式；正式调整前请用本环境脱敏日志样本复核。
!复核四问：生成、透传、按ID拉齐、告别纯时间戳(assets/request-id-propagation-gate-body-03-2026-08-20.png)