Revel框架需手动实现链路追踪：在首个Filter生成并透传X-Request-ID，通过日志前缀、DB上下文、HTTP请求头绑定该ID，并显式传递至异步goroutine，否则链路易断裂。
Revel 框架本身不内置链路追踪能力，必须靠手动注入 X-Request-ID 并配合中间件透传、日志绑定、下游调用携带来拼出完整链路。没有自动 Span 创建和上报机制，这点和 Hyperf/tracer 或 Spring Cloud Sleuth 有本质区别。
如何在 Revel 入口生成并透传 X-Request-ID
Revel 没有类似 Nginx 的 $request_id 内置变量，需在第一个 Filter 中生成并写入上下文。推荐在自定义 Filter（如 RequestIdFilter）中完成：
- 检查请求头是否已含
X-Request-ID；若有且格式合法（如 32 位 hex），直接复用，避免覆盖 - 若无，则用
uuid.NewString()或fmt.Sprintf("%d-%s", time.Now().UnixNano(), randStr(8))生成 - 调用
c.Request.Header.Set("X-Request-ID", id)并存入c.Params.Set("request_id", id)，供后续 Controller/Interceptor 使用 - 务必放在所有业务 Filter 之前（比如在
PanicFilter后、RouterFilter前），否则路由失败时 ID 就丢了
怎样让日志、DB 查询、HTTP 调用都带上这个 ID
关键不是“打日志”，而是让所有可观测输出都染色。Revel 的 revel.INFO/revel.ERROR 默认不包含上下文，需主动注入：
- 日志：在每个 Controller 的
Begin()方法里调用revel.AppLog.SetPrefix("[req:" + c.Params.Get("request_id") + "] ")；或更稳妥地，在自定义LoggerFilter中用zap.String("request_id", id)构建结构化日志字段 - DB 查询：若用
gorm，可在Session上下文中挂载 ID，并通过logger回调注入到 SQL 日志；若用原生database/sql，需包装Stmt或使用context.WithValue传递 - HTTP 调用：所有出站请求（如调用其他微服务）必须显式设置 header：
req.Header.Set("X-Request-ID", c.Params.Get("request_id"))；若封装了 SDK，务必在 client 初始化时注入 context 传播逻辑
为什么 Revel 的链路容易断在异步 goroutine 里
Revel 的 Filter 和 Controller 运行在主线程 goroutine，但一旦你用 go func() { ... }() 启动异步任务，c.Params 和 revel.AppLog 就不再可用——Go 的 goroutine 不共享栈帧，也没有 MDC 类机制。
- 错误做法：在 goroutine 里直接调用
c.Render()或读c.Params.Get("request_id")→ panic 或空值 - 正确做法：把
request_id作为参数传进 goroutine，或用context.WithValue(context.Background(), key, id)包装后传入 - 特别注意
Interceptor：它的BEGIN/END钩子只在主 goroutine 触发，无法捕获异步分支中的耗时或错误 - 若用了
AsyncTask工具类，必须在Submit时把 ID 显式带进去，否则日志和 trace 就彻底脱钩
真正难的不是生成 ID，而是确保它不被任何环节丢弃或覆盖——从 Nginx proxy_set_header 开始，到 Revel Filter、Controller、goroutine、HTTP Client、下游服务响应头，每一步都可能断裂。最容易被忽略的是：Revel 的 ValidationFilter 和 FlashFilter 会修改响应头，若未做保护，X-Request-ID 可能被意外清除。
