GORM聚合查询需显式使用Select()配合Scan()或Count()等方法，GROUP BY字段须手动指定且与别名严格匹配，复杂场景建议用Raw()。
聚合函数必须配合 Select() 或 Count() 等显式查询方法使用
GORM 不会在 Find() 或 First() 这类结构化结果查询中自动解析聚合字段——它默认期望映射到完整模型结构。直接写 SELECT COUNT(*) FROM users 却调用 Find(&users)，会因字段数不匹配 panic 或静默丢数据。
正确做法是：用 Select() 显式声明聚合表达式，并搭配 Scan()（接收任意类型）或 Count()/Sum() 等专用方法：
// ✅ 正确：Scan 到 int64
var count int64
db.Table("users").Select("COUNT(*)").Scan(&count).Error
// ✅ 正确：用内置 Count 方法（更安全）
count := db.Table("users").Count(&count)
// ❌ 错误：Find 试图把单个 COUNT 结果塞进 User 结构体
var users []User
db.Table("users").Select("COUNT(*)").Find(&users) // panic: scan error on column index 0
GROUP BY 查询必须手动指定字段，GORM 不推断
GORM 不会根据 Select() 中的聚合表达式反向推导 GROUP BY 字段。漏写或写错 Group()，会导致 SQL 报错（如 PostgreSQL 的 “column must appear in the GROUP BY clause”）或 MySQL 的非标准行为（依赖 sql_mode）。
常见场景是按状态统计用户数、按日期汇总订单金额：
立即学习“go语言免费学习笔记（深入）”；
- 所有参与
SELECT但未被聚合函数包裹的字段，都必须出现在Group()中 - 字段名需与数据库实际列名一致（区分大小写），别名无效
- 多个字段用逗号分隔，
Group("status, created_at::date")在 PostgreSQL 中合法，但 SQLite 不支持函数表达式
// ✅ 按 status 分组计数（PostgreSQL/MySQL 均可）
var statuses []struct {
Status string
Count int64
}
db.Table("users").Select("status, COUNT(*) as count").Group("status").Scan(&statuses)
// ❌ Group("s.status") 会失败：表别名 s 未在 Select 中定义
// ❌ Group("Status") 在 PostgreSQL 中可能找不到列（大小写敏感）
聚合结果扫描到结构体时，字段名必须严格匹配别名
GORM 使用反射将查询结果映射到 struct 字段，匹配依据是 SQL 中的列别名（AS 后的名字），而非原始列名或 struct tag。别名缺失、拼写错误或大小写不一致，都会导致字段为零值且无报错。
尤其注意：MySQL 默认忽略大小写，PostgreSQL 和 SQLite 严格区分；GORM 不做别名标准化。
- 务必用
AS显式声明别名，且与 struct 字段名完全一致（包括大小写） - 避免用关键字作别名（如
count、sum），部分驱动可能解析异常 - 若字段名含下划线（如
total_amount），别名也必须用下划线，不能驼峰
// ✅ 安全写法：显式别名 + 匹配字段名
type Stat struct {
Status string `gorm:"column:status"`
TotalOrder int64 `gorm:"column:total_order"`
}
var stats []Stat
db.Table("orders").
Select("status, COUNT(*) AS total_order").
Group("status").
Scan(&stats)
// ❌ totalOrder 字段不会被赋值：别名是 "total_order"，不是 "totalOrder"
复杂聚合（如 HAVING、嵌套子查询）建议用 Raw() 替代链式调用
GORM 的 Having() 仅支持简单条件（如 Having("COUNT(*) > ?", 10)），无法处理带函数、子查询或跨表聚合的逻辑。强行用链式写法容易生成语义错误的 SQL，且调试困难。
当遇到以下情况，直接上 Raw() 更可靠：
-
HAVING条件中引用了聚合函数以外的计算（如HAVING AVG(price) > (SELECT AVG(price) FROM products)） - 需要窗口函数（
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price)） - 多层嵌套聚合（先按天聚合，再算周均值）
注意：用 Raw() 时，参数绑定仍走 GORM 的预处理机制，无需手动拼接 SQL。
// ✅ 复杂 HAVING：用 Raw 避免链式歧义
var results []struct {
Category string
AvgPrice float64
}
db.Raw(`
SELECT category, AVG(price) as avg_price
FROM products
GROUP BY category
HAVING AVG(price) > (
SELECT AVG(price) FROM products WHERE stock > 0
)
`).Scan(&results)
GORM 的聚合支持足够日常使用，但它的抽象层在复杂分析场景下会成为障碍。最易被忽略的是别名匹配规则和 GROUP BY 字段的手动声明——这两个点出问题时往往没有明显报错，只返回空结果或零值。 
