GORM中识别超时SQL的关键是用context.WithValue在Trace()中精准计时，而非依赖LogMode或全局time.Now；必须配置SlowThreshold并启用Warn日志级别，且通过fc()延迟获取SQL以避免开销。
如何识别GORM中执行超时的SQL语句
关键不是等它慢，而是从执行开始就计时，超过阈值立刻记录。GORM v2 的 Logger 接口提供了 LogMode() 和更底层的 Trace() 方法，但真正可控、可埋点的是自定义 gorm.Logger 实现——必须用 WithContext() 注入计时逻辑，否则拿不到单条 SQL 的起始时间。
常见错误是直接在 Info() 里打日志：这时 SQL 已执行完，你只看到结果，看不到耗时源头；或者用全局 time.Now()，但在并发场景下会串上下文。
- 务必在
Trace()的Begin阶段存入context.WithValue(ctx, key, time.Now()) - 在
End阶段取出该时间，与当前时间差值即为真实执行耗时 - 阈值建议设为 100ms（业务库）或 500ms（分析型查询），避免日志刷屏
怎样让GORM日志同时输出SQL和耗时且不干扰正常流程
不要重写整个 Logger 接口，只需嵌套默认 logger（gorm.Logger）并覆盖 Trace()。GORM 的 Config.Logger 允许传入任意实现，只要满足接口即可——这是最轻量、最兼容的做法。
示例核心逻辑：
立即学习“go语言免费学习笔记（深入）”；
type SlowQueryLogger struct {
gorm.Logger
slowThreshold time.Duration
}
<p>func (l *SlowQueryLogger) Trace(ctx context.Context, begin time.Time, fc func() (string, int64), err error) {
end := time.Now()
elapsed := end.Sub(begin)
if elapsed > l.slowThreshold {
sql, rows := fc()
log.Printf("[SLOW] %v | SQL: %s | Rows: %d", elapsed, sql, rows)
}
}注意：fc() 是延迟执行的闭包，确保只在需要时解析 SQL（避免字符串拼接开销）；err 参数已包含失败信息，无需额外判空。
为什么用 context.WithValue 传开始时间比用 map 存更安全
因为 GORM 内部调用 Trace() 时，传入的 ctx 是带 DB 连接上下文的，天然隔离 goroutine。而用全局 map + SQL hash 做键，会引发竞态：多条 SQL 并发执行时，Begin 和 End 可能错配，导致耗时计算错误甚至 panic。
-
context.WithValue()绑定的是本次查询生命周期，随 ctx 自动 cancel - map 方案需手动清理，极易内存泄漏（尤其长连接场景）
- GORM v2.2+ 已在内部 trace 流程中透传 ctx，不用 hack 就能用
上线后发现慢查日志没打出来？检查这三点
不是代码没写对，大概率是配置漏了或环境压测没触发真实路径。
- 确认 DB 初始化时用了
Config.Logger: &SlowQueryLogger{...}，而非仅调DB.Debug() - 检查是否启用了
PrepareStmt: true—— 开启后 GORM 会预编译，Trace()中的sql可能是带 ? 占位符的模板，不是最终执行语句 - 验证阈值单位：
time.Millisecond不是time.Second，100 * time.Millisecond = 100ms，写成100 * time.Second就永远不触发
真正难排查的是 ORM 层外的慢查：比如事务里混了 HTTP 调用、JSON 解析或循环 DB 查询。这类不会进 Trace()，得靠 pprof 或分布式 trace 工具补位。
