Beego ORM的debug开关仅在RegisterDataBase后、首次NewOrm前设置才生效，中间件中设置无效；需在main.go或models/init.go中配置，或自行封装QuerySeter拦截方法并添加时间戳、request_id等链路信息。
中间件里拿不到 ORM 实例，orm.Debug = true 不起作用
很多人在中间件里直接写 orm.Debug = true，发现日志根本没输出。这是因为 Beego ORM 的 debug 开关只在 orm.RegisterDataBase() 之后、且首次调用 orm.NewOrm() 之前生效；中间件执行时 ORM 实例早已初始化完毕，此时设 debug 是无效的。
真正能起作用的方式只有两个：
- 在
main.go或models/init.go中，RegisterDataBase调用后、任何NewOrm()前，显式设置orm.Debug = true - 或者彻底绕过 debug 开关，自己封装一层
QuerySeter或拦截o.Raw()、o.Read()等方法，在调用前后打点
想记录 SQL + 参数 + 耗时，必须手动加时间戳
Beego ORM 的 debug 日志只输出 SQL 和 Args，不带任何时间信息。你看到的日志类似这样：
2026/11/04 00:55:12 [ORM] - SELECT * FROM user WHERE id = ? [1]
但没有毫秒级耗时，也没法关联请求 ID。要补全这个能力，得在中间件或自定义 ORM 封装层里动手：
- 用
time.Now()记录起点，在o.All()/o.Read()返回后算差值 - 把
ctx.Input.Ctx.Request.Context()里的request_id（如果用了beego-Requestid中间件）一并打进去 - 避免直接用
log.Println，改用logs.Info并带上file:line（需提前调用logs.SetLogFuncCallDepth(3)）
链路追踪不能只靠 SQL 日志，得串联上下文
单纯记录 SQL 耗时只是单点观测，真正的链路追踪需要把 DB 查询和当前 HTTP 请求生命周期串起来。关键点有三个：
- 确保中间件顺序：先跑
RequestId中间件，再跑你的 SQL 日志拦截器，否则拿不到request_id - 不要在每个控制器里重复 new orm，统一用
ctx.Input.Ctx.Request.Context()传参，或通过context.WithValue注入 trace ID - 生产环境禁用全量 SQL 日志，改用采样策略——比如只记录
duration > 300ms的查询，或对特定路由（如/api/v1/report）开启全量
别忘了 ORM 层的性能陷阱比慢 SQL 更隐蔽
即使你把 SQL 执行时间压到 5ms，QueryTable("order").All(&orders) 返回 2000 条记录时，Beego ORM 仍可能花掉 80ms 在反射赋值和类型转换上。这不是日志能暴露的问题，但会拖垮整个链路。
这时候 SQL 日志反而会误导你——它显示“很快”，但真实响应时间很长。解决办法只有两个：
- 用
o.Raw(sql).Values(&list)绕过结构体映射，直接取map[string]string - 对高频大结果集接口，改用原生
database/sql+rows.Scan()，自己控制字段绑定
链路追踪数据里如果看到 DB 阶段耗时远低于总耗时，优先怀疑 ORM 映射开销，而不是数据库本身。
