Beego ORM 的 SQL 日志需在 orm.NewOrm() 前设置 orm.Debug = true，且 logs.BeeLogger 必须启用 console 或 file 引擎，否则日志不输出；参数以 ? 占位符显示属正常行为。
开启 orm.Debug 后日志不输出？检查初始化顺序
Beego ORM 的 SQL 日志依赖 orm.Debug = true，但它必须在 orm.NewOrm() 之前设置，否则无效。很多人把这行写在 main() 末尾或控制器里，结果完全看不到日志。
-
orm.Debug是全局变量，只影响后续创建的Orm实例，不是运行时开关 - 注册数据库（
orm.RegisterDataBase）和模型（orm.RegisterModel）可以放在前面，但orm.Debug = true必须紧挨着orm.NewOrm()之前，或至少在它调用前完成赋值 - 如果用了
o := orm.NewOrm(); o.Using("xxx")，那orm.Debug仍需在NewOrm()前设 ——Using不影响 debug 开关
日志里看到的 SQL 为什么参数没替换？这是正常行为
Beego ORM 打印的是带问号占位符的原始 SQL，例如 SELECT * FROM account WHERE name = ? AND status = ?，不会展开成 WHERE name = 'dangdang' AND status = 1。这不是 bug，而是驱动层（如 go-sql-driver/mysql）本身不提供参数展开能力，ORM 也未做模拟。
- 想确认实际执行值，得结合
fmt.Printf手动打印传入的参数切片，或改用o.Raw(sql).Values(&list)时在调用前 log 参数 - 某些调试场景下可临时加一层 wrapper：用
fmt.Sprintf模拟替换（仅限简单字符串/数字，注意 SQL 注入风险），但生产环境禁止 - 别依赖日志判断参数是否“对得上”，重点看返回结果和
err是否为nil
生产环境禁用 orm.Debug，但又想查慢查询？换方案
orm.Debug = true 会显著拖慢性能，因为每条 SQL 都要格式化、拼接、写到日志器，线上必须关。但你仍需要可观测性：
- 用 MySQL 自身的
slow_query_log+long_query_time捕获真实慢 SQL，和 ORM 无关，最可靠 - 在关键查询前后打点：用
time.Now()和time.Since()记录耗时，配合logs.Info输出，例如logs.Info("query account by id=%d, cost=%v", id, time.Since(start)) - 若必须看 SQL 文本，可封装一个带日志的
Raw调用：logs.Debug("raw sql: %s, args: %v", sql, args)，再执行o.Raw(sql).Params(args...)
日志输出目标不是 console？确认 logs.BeeLogger 配置生效
即使 orm.Debug = true，如果 Beego 的全局日志器 logs.BeeLogger 没启用 console 或 file 引擎，你也看不到任何输出。
- 默认
BeeLogger只启了 console，但如果代码中调过logs.SetLogger("file", ...)却没保留 console，SQL 日志就全进文件了，容易被忽略 - 检查是否误调了
logs.Reset()或BeeLogger.DelLogger("console")—— 这会让 debug 输出彻底消失 - 多引擎共存是允许的：
logs.SetLogger("console"); logs.SetLogger("file", `{"filename":"sql.log"}`)，这样 SQL 日志既打屏又落盘
Beego ORM 的 SQL 日志机制很轻量，但依赖初始化时机和日志器状态两个隐性条件；一旦漏掉其中一环，就变成“开了却像没开”。最常被忽略的是：debug 开关必须在 ORM 实例创建前设，且日志器引擎必须活着。
