Revel需手动实现全链路追踪：仅在入口生成X-Request-ID，通过Filter兜底注入、HTTP出站调用显式透传、日志绑定MDC、DB/MQ/Redis手动携带，缺一环即断链。
Revel 本身不内置链路追踪，必须靠手动注入 X-Request-ID + 显式透传 + 日志上下文绑定才能实现可用的全链路追踪。 它不像 Spring Cloud Sleuth 那样自动织入 Span，也不像 ALB 那样能自动生成 traceparent。想在 Revel 里看到一次请求从网关到 DB 的完整路径，关键不是“开个开关”，而是把 ID 在每个出站调用和每条日志里都稳稳地带上。
如何在 Revel 中生成并注入 X-Request-ID
必须只在入口做一次生成，后续所有环节禁止覆盖。推荐在网关层（如 Nginx 或 ALB）完成，Revel 仅作兜底：
- 若使用 ALB：开启链路追踪后，ALB 会自动注入
traceparent，但X-Request-ID需自行提取并写入日志上下文（例如从traceparent的traceid段截取或拼接） - 若用 Nginx：在
location块中加proxy_set_header X-Request-ID $request_id;，并确保log_format包含$request_id - Revel 兜底逻辑：在自定义 Filter（如
RequestIdFilter）中检查c.Request.Header.Get("X-Request-ID")，为空则生成 UUID（用github.com/google/uuid），再设回 Header 并存入 MDC（如revel.Config.Set("request.id", id)或用第三方库如logrus.Entry.WithField）
为什么 c.Params.Get("X-Request-ID") 永远拿不到值
c.Params 只聚合查询参数、路径参数、表单字段，不包含原始 HTTP Header。这是 Revel 的设计限制，不是 bug：
- 正确读法是
c.Request.Header.Get("X-Request-ID")—— 必须走http.Request.Header - 如果用了 ALB 注入的
traceparent，需手动解析：用正则提取traceid（格式为00-([0-9a-f]{32})-），再作为X-Request-ID使用 - 不要试图在路由文件里写
GET /api?X-Request-ID:string—— Revel 不支持 query 参数声明，该写法直接导致路由匹配失败
如何让下游 HTTP 调用自动带上 X-Request-ID
Revel 不接管你的 HTTP Client，所有出站请求都得自己动手补头。常见场景包括调用其他微服务、发通知、查第三方 API：
- 用
net/http.Client时，在发起请求前显式设置：req.Header.Set("X-Request-ID", c.Request.Header.Get("X-Request-ID")) - 若用
resty或gorequest，在 client 初始化时加全局 header：resty.SetHeader("X-Request-ID", id)，但注意这会污染所有请求；更安全的是每次 request 实例化后单独 set - 数据库操作（如 GORM）无法透传 ID，只能靠日志打点：在 SQL 执行前后手动记录
request_id和语句，或使用 GORM 的Logger接口注入上下文字段 - Redis、MQ 等中间件同理：在
Publish/Set前，把X-Request-ID写进消息 payload 或额外字段（如headers["X-Request-ID"]）
日志里始终看不到 X-Request-ID？检查这三个地方
最常被忽略的不是生成逻辑，而是日志输出是否真绑定了当前请求上下文：
- 确认你没在
revel.AppLog或revel.TRACE之外另起 logger（比如直接用log.Printf）—— 这些不会继承 MDC - Revel 默认日志不支持结构化字段，若用
logrus或zerolog，必须在 Filter 中用log.WithField("request_id", id)创建新 entry，并绑定到c或全局 context - 测试时用
revel test启动，c.Request是 mock 对象，Header默认为空 map，需在测试 setup 里手动c.Request.Header.Set("X-Request-ID", "test-123")
链路追踪在 Revel 里不是配置项，而是一连串不能跳过的手动动作：入口生成 → 日志绑定 → 出站透传 → 下游接收 → 日志落盘。少一环，整条链就断在那个节点之后。最容易被绕开的是数据库和异步任务，它们不走 HTTP，但恰恰是耗时黑洞最常藏身的地方。
