AfterFind 不适合慢查询监控，因其在结果反序列化后触发，无法获取真实耗时、SQL原文和参数，且对Count、Raw等查询无效；应使用BeforeQuery/AfterQuery钩子或GORM.Logger接口实现精准计时。
为什么 AfterFind 钩子不适合做慢查询监控
因为 AfterFind 在结果反序列化完成后才触发，此时 SQL 已执行完毕、连接可能已释放，你拿不到真实耗时、SQL 原文和参数绑定值。更糟的是，它对 Count、Raw、Session 等非结构化查询完全不生效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
BeforeQuery和AfterQuery是 GORM v2 唯一能稳定捕获所有查询生命周期的钩子，必须用这两个 - 别在钩子里做 I/O（如写文件、发 HTTP），否则会拖慢所有请求；先存内存或发到缓冲队列
- 注意 GORM v1 没有
AfterQuery，v1 用户得升到 v2 或改用Logger接口
如何用 GORM.Config.Logger 替代钩子做精准计时
GORM 自带的 Logger 接口比钩子更底层，能拿到 context.Context、原始 SQL、参数、错误和确切耗时——而且默认就启用，不用额外注册。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 实现
gorm.Logger接口的LogMode方法设为log.Info级别，避免日志爆炸 - 重写
Trace方法，在elapsed超过阈值（比如 200ms）时才记录完整 SQL 和rowsAffected - 务必调用
sql.Rows().Close()前再打日志，否则rowsAffected可能为 -1 - 示例关键片段：
func (l slowQueryLogger) Trace(ctx context.Context, begin time.Time, fc func() (string, int64), err error) { elapsed := time.Since(begin) if elapsed > 200*time.Millisecond { sql, rows := fc() log.Printf("[SLOW] %s | %dms | rows:%d | err:%v", sql, elapsed.Milliseconds(), rows, err) } }
db.Session(&gorm.Session{Context: ctx}) 会影响慢查询日志吗
不影响日志本身，但会影响你能拿到的信息粒度。GORM 的 Session 会覆盖当前 Context，如果你在 Trace 里想从 ctx 中取 traceID 或用户 ID，就必须确保 session 创建时传入了带这些值的 Context。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要在中间件里统一塞
context.WithValue后直接传给 DB，GORM 有些操作（如预加载）会新建 session 并丢掉原 context - 推荐在每个查询前显式构造 session：
db.WithContext(ctx).Session(&gorm.Session{PrepareStmt: true}) -
PrepareStmt: true会让日志中 SQL 显示为带 ? 占位符的形式，更安全也更利于聚合分析
MySQL 的 long_query_time 和应用层监控冲突吗
不冲突，但定位逻辑不同：MySQL 的 long_query_time 是服务端视角，只记录到达 MySQL 的语句；而 GORM 日志是客户端视角，包含 DNS 解析、连接池等待、网络往返、GORM 序列化等全链路耗时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把 MySQL 的
long_query_time设为 100ms，GORM 日志阈值设为 200ms，两者互补：前者抓真慢 SQL，后者抓应用瓶颈（比如连接池堵死） - 如果发现 GORM 日志里耗时长但 MySQL 慢日志没记录，大概率是卡在连接获取或参数构建阶段，不是 SQL 本身问题
- 注意 GORM 的
NowFunc配置会影响Trace计时起点，保持默认即可，别自定义成纳秒级函数导致误差
真正难的是区分“SQL 慢”和“GORM 慢”——比如 Preload 嵌套多层时，日志里一条 SQL 耗时正常，但整体接口超时，这时候得开 Debug 模式看 GORM 实际生成了几条语句。
