Group()必须配合聚合函数才有意义，单独使用仅触发语法分组而无统计价值；Having()是过滤分组结果的唯一合法方式，Where()对聚合值无效；Order()和Limit()顺序影响分页稳定性，“每组取N条”需用窗口函数或应用层控制。
Group() 必须配合聚合函数才能拿到有意义的结果
单独写 DB.Group("user_id") 不会报错，但查出来的数据是原始行的无序堆叠——GORM 不会自动加 COUNT、SUM 等聚合函数，也不会帮你选字段。你看到的可能是重复的 user_id + 随机一条记录，这不是分组统计，只是 GROUP BY 语法生效了而已。
真正有用的分组必须显式指定聚合逻辑：
-
DB.Model(&Order{}).Select("user_id, COUNT(*) as count").Group("user_id")→ 统计每个用户的订单数 -
DB.Model(&Order{}).Select("DATE(created_at) as date, SUM(amount) as total").Group("DATE(created_at)")→ 按天汇总销售额 - 多个分组字段要写成
Group("user_id, status")，不能拆成两次Group
Having() 是过滤分组结果的唯一合法方式
Where() 对分组后的聚合值完全无效。比如想查“订单总额超 1000 的用户”，写 Where("SUM(amount) > 1000") 会触发 SQL 错误或生成非法语句——因为 SUM 是聚合函数，不能出现在 WHERE 子句中。
正确做法是用 Having()，它作用于 GROUP BY 之后的中间结果集：
DB.Table("orders").Select("user_id, SUM(amount) as total").Group("user_id").Having("SUM(amount) > ?", 1000)-
Having中的字段名必须和Select中出现的别名或原始列一致，比如用了as total，就不能在Having里写"total > ?"（PostgreSQL 严格拒绝，MySQL 有时容忍但不可靠） - 多个条件用
Having("SUM(amount) > ? AND COUNT(*) >= ?", 1000, 5)
Order() 和 Limit/Offset 的位置直接影响分页稳定性
如果目标是“取前 20 个高消费用户”，顺序必须是：Order("total DESC").Limit(20)。反过来写 Limit(20).Order("total DESC")，数据库会先随机取 20 条再排序，结果不可控，翻页时数据会跳变或重复。
更关键的是排序字段要有确定性：
- 单用
Order("total DESC")不可靠——不同用户的 total 可能相同，数据库无法保证相同 total 下的行序稳定 - 建议补上主键或时间戳：
Order("total DESC, user_id DESC")或Order("total DESC, created_at DESC, id DESC") - 避免
Order("RAND()")分页，不支持续查，且全表扫描性能极差
“每组取 N 条”不是 Group 能解决的问题
GORM 的 Group() 天然不支持“每个用户取最新 3 笔订单”这类需求。它只返回每组一条聚合结果，而你要的是每组多条明细数据的子集。
这种场景必须换思路：
- 应用层控制：先查出所有 user_id，再对每个 ID 单独执行
Where("user_id = ?").Order("created_at DESC").Limit(3)—— 简单但 N+1 查询风险高 - 窗口函数（推荐）：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，GORM v1.25+ 不原生支持，需手拼 SQL 或封装为Scopes - 子查询嵌套：外层筛选
rn ，内层计算行号，注意子查询必须用 <code>(?)包裹，否则 GORM 当作普通字符串参数处理
最容易被忽略的一点：分组查询的语义边界非常清晰——Group 是为了降维统计，不是为了切片明细。一旦混淆这个前提，后续所有分页、排序、过滤都会走偏。
