Beego ORM 的 Count() 方法最轻量，仅返回符合条件的记录数；复杂聚合需用 ValuesList() 配合原生 SQL；Distinct() 不能替代 COUNT(DISTINCT)；ValuesList 结果取值须谨慎类型断言。
Count() 方法直接获取记录总数
Beego ORM 的 QuerySeter 提供了 Count() 方法，这是最轻量、最常用的聚合统计方式，适用于“查有多少条符合条件的记录”这种场景。
它不加载任何数据到内存，只返回一个 int64 数字，性能远优于先 All() 再 len()。
-
Count()必须在调用Filter()、Exclude()等条件方法之后链式调用，否则统计的是全表 - 不支持指定字段或去重统计（如
COUNT(DISTINCT city)），只能等价于COUNT(*) - 返回值是
(int64, error)，务必检查error—— 常见错误如数据库连接中断、表不存在时会返回非 nil 错误
示例：
o := orm.NewOrm()
qs := o.QueryTable(&User{})
total, err := qs.Filter("city", "shenzhen").Filter("init_time__gt", "2024-01-01").Count()
if err != nil {
// 处理错误，不要忽略
}
fmt.Printf("深圳用户数：%d\n", total)
ValuesList + 自定义 SQL 实现分组/去重/多字段聚合
Beego ORM 原生不支持 GROUP BY、AVG、MAX 或 COUNT(DISTINCT ...) 这类复杂聚合。想做城市用户数分布、平均年龄、最新注册时间等，得绕过 Count()，改用 ValuesList() 配合原生 SQL。
ValuesList() 本质是执行 SELECT ... FROM ... 并把结果转成 []orm.ParamsList，你可以塞任意合法 SQL 表达式进去。
- 必须用
FilterRaw()或直接拼接 SQL 字符串，不能依赖Filter("city__in", ...)这类高级表达式 —— 它们只适配 WHERE 子句，不参与 SELECT 列 - SQL 中的列别名（如
COUNT(*) AS cnt）会被自动映射为 map key，取值时用item["cnt"] - 注意 SQL 注入风险：所有用户输入必须用参数化查询，例如
qs.FilterRaw("city = ?", city)，而非字符串拼接
示例（按城市统计用户数）：
var result []orm.ParamsList
qs := o.QueryTable(&User{})
_, err := qs.FilterRaw("1=1").ValuesList(&result, "city", "COUNT(*) AS cnt")
// 注意：FilterRaw("1=1") 是占位写法，避免空条件报错；真实场景应加业务过滤
if err == nil {
for _, item := range result {
city := item[0].(string)
cnt := item[1].(int64)
fmt.Printf("%s: %d 人\n", city, cnt)
}
}
Distinct() 只能去重主键，不能替代 COUNT(DISTINCT)
Distinct() 看起来像能解决去重统计，但它在 Beego ORM 中有严重限制：它只对主键字段生效，且底层生成的是 SELECT DISTINCT `id` FROM ...，目的是配合 All() 去重结果集，**不是为聚合设计的**。
- 调用
qs.Distinct().Count()仍等价于COUNT(DISTINCT id)，无法统计COUNT(DISTINCT city) - 如果模型没显式声明
pktag，Distinct()可能静默失效或 panic - 即使你强行用
ValuesList(&r, "city")后在 Go 层去重，大数据量下内存和 CPU 开销远高于数据库层聚合
结论：需要 COUNT(DISTINCT xxx) 就老实用 FilterRaw() + 原生 SQL，别碰 Distinct() 做统计。
聚合结果类型转换容易 panic
用 ValuesList() 拿到聚合结果后，取值时类型断言极易出错。比如数据库返回 INT，但你写了 item[1].(int)，实际可能是 int64 或 uint64；又或者 NULL 值被转成 nil，直接断言会 panic。
- 永远用
fmt.Printf("%#v", item)先看原始结构，确认每个字段的真实 Go 类型 - 对数字字段，统一用
item[i].(int64)（MySQL int 默认映射为 int64） - 对可能为 NULL 的字段，先判断是否为
nil：if v := item[2]; v != nil { val := v.(string) } - 别信文档里“返回类型一致”的说法 —— 不同驱动、不同 MySQL 版本、不同字段定义（TINYINT vs BIGINT）都可能导致类型漂移
最稳妥的方式是封装一层类型安全的取值函数，而不是每次手写断言。
