gorm.WithContext()是唯一可靠入口，必须每次请求动态调用以透传traceID；自定义logger需在日志方法内显式从ctx提取traceID；事务和子goroutine中须手动传递ctx；OTel插件不自动注入日志字段。
gorm.WithContext() 是唯一可靠入口
gorm 本身不感知 context 或 traceID，所有透传必须显式调用 WithContext()。不调用它，哪怕你在上层 context 里塞了 traceID，gorm 日志和 SQL 执行日志里也绝对看不到。这不是配置问题，是设计约束。
常见错误是只在初始化时传一次全局 context：db = db.WithContext(ctx)，这会让所有后续查询都复用同一个 ctx —— 多个请求并发时 traceID 混乱。正确做法是每次执行前动态绑定：
- HTTP handler 中拿到带 traceID 的
ctx后，立即调用db.WithContext(ctx)得到新实例 - 该实例仅用于本次请求的 DB 操作，不可复用或缓存
- 若用了 gorm 的
Session()，也必须确保 session 是基于当前请求 ctx 创建的
自定义 logger 必须从 context 提取 traceID
gorm 的 Config.Logger 接口（如 zap.Logger 或自定义 logger.Interface）不会自动读 context。你传给它的 logger 对象本身不含 trace 上下文，所以日志行里不会自动出现 trace_id 字段。
解决方法不是改 logger 实例，而是在每条日志生成前动态注入字段：
- 实现
LogMode()或封装TraceLogger，在Info()、Warn()等方法内调用ctx.Value(traceKey{})提取 traceID - 不要用
logger.With(zap.String("trace_id", id))预绑定——id 是请求级变量，预绑定会导致跨请求污染 - SQL 日志中建议加前缀：例如
[trace_id=abc123] SELECT * FROM users WHERE id = ?，方便 Loki 正则提取
事务和子 goroutine 中 traceID 容易丢失
gorm 的 Transaction() 和 Session() 默认不继承父 context，尤其当你在事务里启动新 goroutine（比如异步写日志、发消息），context.Background() 一用就断链。
关键动作必须显式传 ctx：
db.Transaction(func(tx *gorm.DB) error { return tx.WithContext(ctx).Create(&u).Error })- 子 goroutine 启动时：用
go processItem(ctx, item)，而非go processItem(context.Background(), item) - DB 回调函数（如
AfterFind）里没有隐式 ctx 可用，需提前把 traceID 作为参数传入或通过 closure 捕获
OpenTelemetry + gorm 插件仍需手动处理 context
即使你用了 go.opentelemetry.io/contrib/instrumentation/gorm.io/gorm/v2/otelgorm 这类插件，它只负责自动创建 span 并上报，**不负责把 traceID 注入 SQL 日志文本**。日志字段和 span 数据是两套系统。
这意味着：
- OTel 插件能让你在 Jaeger 里看到 DB 调用耗时，但查不到对应 SQL 日志 —— 除非你同时做了上面三步的日志字段注入
-
otelgorm.WithTracerProvider(tp)不会改变 gorm 的 logger 行为，Config.Logger仍需独立配置 - 如果用了 W3C
traceparent格式，解析后得到的traceID字符串要手动喂给日志逻辑，插件不代劳
最常被忽略的一点：gorm 的 WithContext() 只影响当前操作的 context 绑定，它不修改 underlying *sql.DB 的行为，也不触发任何钩子。traceID 是否出现在日志里，100% 取决于你写的 logger 实现是否主动去 ctx.Value() 里捞 —— 没有魔法，只有显式提取。
