Gin中间件不适合直接做慢SQL监控，因其仅感知HTTP请求生命周期，无法获取SQL语句、执行时长等业务层信息；应使用driver.WrapConn在数据库驱动层拦截，配合context.WithValue透传HTTP上下文，并异步记录去参化SQL、耗时、调用栈及路径等字段。
为什么 Gin 中间件不适合直接做慢 SQL 监控
因为 Gin 的中间件只感知 HTTP 请求生命周期，而 SQL 执行发生在业务逻辑层（比如 database/sql、gorm 或其他 ORM 内部），中间件本身拿不到 SQL 语句、执行时长、参数等上下文。强行在中间件里埋点捕获 SQL，要么需要侵入数据库驱动，要么依赖全局钩子（如 sql.Register），但这类方式和中间件无直接关系，也容易漏掉非 HTTP 触发的 SQL（如定时任务、后台协程）。
用 database/sql 的 driver.WrapConn 实现真正的慢 SQL 拦截
Go 标准库从 1.19 开始支持 driver.WrapConn，允许你包装底层连接，在 PrepareContext、QueryContext、ExecContext 等关键方法上加监控。这是目前最轻量、无 ORM 绑定、且能精准拿到 SQL 和耗时的方式。
实操建议：
- 不要修改现有
sql.Open返回的*sql.DB，而是在创建后用db.SetConnMaxLifetime等保持配置一致的前提下，用driver.WrapConn包装其内部驱动 - 慢阈值建议设为
500ms起步，生产环境可按接口 SLA 动态调整（例如核心支付接口设为200ms） - 记录字段至少包含：
sql（去参化后的语句）、duration、stack（调用栈，用runtime.Caller获取）、http_path（若能从 goroutine local context 透传） - 避免在拦截器中做阻塞操作（如写磁盘、发 HTTP），应异步投递到 channel 或通过
log/slog的异步 handler 处理
如何把 HTTP 上下文（如 path、trace_id）带进 SQL 监控
标准 database/sql 不携带任何请求上下文，必须手动透传。Gin 的 c.Request.Context() 是唯一可靠来源，但不能直接塞进 db.QueryContext —— 因为那只是控制超时，不是传递元数据。
推荐做法是结合 context.WithValue + 自定义 context.Context key：
- 在 Gin 中间件中：用
c.Request = c.Request.WithContext(context.WithValue(c.Request.Context(), sqlCtxKey, map[string]string{"path": c.FullPath(), "trace_id": traceID})) - 在
WrapConn的QueryContext实现里，从ctx.Value(sqlCtxKey)取出 map 并合并进慢日志 - 注意：key 必须是私有类型（如
type sqlCtxKey string），不能用string直接当 key，否则易冲突
GORM 用户别绕开 GORM 的 Hooks，但得避开常见陷阱
如果你用的是 GORM v2，它原生支持 Callback 和 Plugin，比硬套 WrapConn 更简单，但默认 Hooks 不包含完整 SQL（clause 未格式化）且不自动带上下文。
关键配置点：
- 注册 Hook 时用
session.AddError或自定义logger替代fmt.Println，否则 panic 会吞掉错误 - 启用
gorm.Config.PrepareStmt: true后，BeforePrepareHook 才能稳定拿到最终 SQL 字符串；否则多数场景只能拿到带问号的模板 - 慢判断必须放在
AfterFind/AfterSave等“执行后” Hook，且要自己记录开始时间（ctx.Value存time.Time），不能依赖 Hook 调用顺序推断耗时 - GORM 的
WithContext方法不会自动把 Gin context 透传到底层database/sql，仍需配合上面提到的context.WithValue方式补全元数据
真正难的不是埋点，而是让慢 SQL 日志既能定位到具体代码行，又不拖慢正常请求 —— 这要求所有耗时采集必须无锁、无分配、且 stack trace 截取深度严格限制（比如只取前 3 层）。
