Beego ORM用Raw查询转map[string]interface{}需调用Values(&maps)，唯一正解；ValuesList和ValuesFlat丢失字段名，不适用。示例：o.Raw("SELECT id, name FROM user").Values(&maps)。
Beego ORM怎么用 Raw 查询并转成 map[string]interface{}
直接用 Raw 是最可控的方式，尤其当 SQL 涉及多表、聚合或别名字段时。Beego ORM 的 QueryTable 的 All 或 One 方法默认只支持结构体映射，不原生支持动态 map；绕过结构体约束必须走 Raw + 手动扫描。
常见错误是试图对 QueryTable("user").Filter("id", 1).All(&result) 传入 map[string]interface{} 类型变量——会 panic，因为 ORM 内部要求目标必须是切片或结构体指针。
-
Raw返回的是*orm.RawSeter，调用Values(&maps)可直接填充[]map[string]interface{} - 注意：字段名默认是数据库列名（小写），若 SQL 中用了别名（如
SELECT name AS user_name），则 key 就是"user_name" - 所有值都是
interface{}，实际使用前需类型断言，比如v["id"].(int64)或v["created"].(time.Time)
var maps []map[string]interface{}
o.Raw("SELECT id, name, status FROM user WHERE status = ?", 1).Values(&maps)
// maps[0] 就是 map[string]interface{}{"id": 123, "name": "alice", "status": 1}
为什么不用 ValuesList 或 ValuesFlat
这两个方法返回的是 [][]interface{} 和 []interface{}，丢失字段名信息，无法构成键值对映射。如果你只要值、不要 key（比如导出 CSV），它们更轻量；但目标是 map，就完全不适用。
-
ValuesList：每行是[]interface{}，顺序依赖 SELECT 字段顺序，无 key，易错位 -
ValuesFlat：把所有结果摊平成一维 slice，彻底无法区分行和列 - 只有
Values会保留字段名作为 map key，是唯一正解
想自动转 map 但又不想写 SQL？小心 LoadRelated 和反射陷阱
有人尝试先查结构体，再用 json.Marshal + json.Unmarshal 转 map——可行但低效且丢类型（所有数字变 float64，time 变字符串）。更隐蔽的问题是 Beego 的 struct tag（如 orm:"column(id)"）不会影响反射生成的 map key 名，key 仍是 Go 字段名（"Id"），而非数据库列名（"id"）。
- 如果必须用结构体中转，建议显式定义 map 并逐字段赋值，控制 key 名和类型
-
LoadRelated只用于关联查询预加载，不能改变主表结果的返回形态 - 别依赖
reflect.StructTag.Get("json")去模拟，Beego 不保证 tag 解析逻辑与 encoding/json 一致
性能和兼容性要注意什么
Values 内部仍走 database/sql 的 Rows.Scan，性能接近原生驱动，但比纯结构体映射略慢（因要构建 map 和反射取字段名）。在 MySQL 下没问题；PostgreSQL 需确保 pg 驱动已注册（_ "github.com/lib/pq"），否则 Raw 会报 sql: unknown driver "postgres"。
- 高并发下避免复用同一个
orm.Ormer实例做大量Raw查询，应确保每次调用o := orm.NewOrm()获取新实例（Beego 默认是协程安全的，但自定义事务需手动管理） - SQLite 不支持参数化查询中的命名占位符（
:name），只认?，统一用问号更稳妥 - 字段为 NULL 时，对应 map value 是
v["xxx"] == nil
Beego ORM 的 map 转换没有“银弹”，Raw().Values() 是边界最清晰、行为最可预测的路径。别被文档里零散的 ValuesList 示例带偏，真正需要键值对时，SQL + Values 就是事实标准。
