Preload不能用于精确统计，应使用Joins+Group+Select：需显式Join关联表、Group主键分组、Select聚合字段（如COUNT(orders.id) AS order_count），且条件过滤须写入ON子句而非Where，避免LEFT JOIN退化为INNER JOIN。
Preload 不能用于精确统计，Joins + Group + Count 才是可靠方案。想在查主表的同时拿到每个用户的订单数？别用 Preload("Orders")，它会把所有订单全拉下来，count 还得自己遍历算，既慢又不准。
为什么 Preload 无法替代 count 统计
Preload 的本质是“先查主表，再发子查询”，它不生成 COUNT 聚合，也不做分组；哪怕你只想要一个数字，它也会把全部关联记录加载进内存。更糟的是，如果用户有 10 万订单，Preload("Orders") 就真会查出 10 万条记录——而你只需要一个 order_count 字段。
- 调用
db.Preload("Orders").Find(&users)后，len(user.Orders)是运行时计算，不是数据库聚合，无法用于 WHERE 或 ORDER - 嵌套
Preload("Orders.Items")会触发笛卡尔积，len(users[0].Orders[0].Items)可能远大于实际值 - 没有事务一致性保障：主表查完到子查询执行之间，数据可能已被删改
用 Joins + Group + Select 实现精准 count
要查「每个用户的订单数」，必须让数据库完成聚合，再映射回结构体。核心是三要素缺一不可：Joins 拉关联表、Group 按主键分组、Select 显式声明聚合字段。
- 写法示例：
db.Select("users.*, COUNT(orders.id) AS order_count").Joins("left join orders on orders.user_id = users.id").Group("users.id").Find(&users) - 必须加
Group("users.id")，否则COUNT返回的是全表总数，不是每个用户的局部计数 -
AS order_count的别名需与结构体字段名一致，如OrderCount uint `gorm:"column:order_count"` - 若用户无订单，
order_count为0（因LEFT JOIN），不是NULL；若要区分，改用COALESCE(COUNT(orders.id), 0)
带条件的关联统计（如只算已支付订单）
关联表过滤条件不能放 Where，否则 LEFT JOIN 退化为 INNER JOIN，没订单的用户直接消失。正确做法是把条件写进 ON 子句。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
db.Where("orders.status = ?", "paid").Joins("left join orders...")→ 用户丢失 - 正确写法：
db.Joins("left join orders ON orders.user_id = users.id AND orders.status = ?", "paid").Group("users.id").Select("users.*, COUNT(orders.id) AS paid_order_count") - 注意：此时
COUNT(orders.id)只统计满足status = 'paid'的行；未匹配的仍为0 - 若需同时统计总单数和已支付单数，可加多个
COUNT(CASE WHEN ...)，但字段名需唯一且结构体字段对齐
统计 + 分页的常见陷阱
直接在带 Joins 和 Group 的语句上加 Limit/Offset 很危险——数据库先分组再分页，但分组前原始行数可能远超预期，导致分页错位。
- 安全做法：先用子查询拿总数，再用
IN查 ID 列表，最后Preload关联数据（适合中等数据量） - 高效做法：用两个独立查询 —— 第一个查
SELECT users.id FROM users LEFT JOIN ... GROUP BY ... LIMIT 10 OFFSET 20，第二个用WHERE id IN (?)+Preload - 切记不要在
Group查询里省略SELECT主表所有字段：GORM 默认只选主表字段，关联聚合字段会被丢弃，除非显式写进Select
最易被忽略的一点：GORM 对 GROUP BY 的字段校验极松，Group("id") 和 Group("users.id") 在某些方言下行为不同；生产环境务必统一用带表名的完整字段名，并开启 Debug() 看真实 SQL。
