Count() 返回 int64 且为终值方法，需传入变量地址；Model() 必须在 Where 前指定表；带 Joins 时默认统计组合行数，应显式用 DISTINCT 或子查询；Count() 不走缓存、不受 Preload 影响。
Count() 方法直接返回 int64，不是 error 或 *gorm.DB
很多人写 Count() 时习惯性接 Error 或继续链式调用，结果发现返回值类型不对、编译报错或统计结果始终是 0。这是因为 Count() 是终值方法：它不返回 *gorm.DB，而是把结果写入你传入的指针变量中。
正确做法是提前声明一个 int64 变量，用地址传给 Count()：
var total int64
db.Where("status = ?", "active").Model(&User{}).Count(&total)
常见错误现象：db.Count().Error 报错（Count() 没有 Error 字段）、db.Count() > 0 编译失败（返回 void）、db.Where(...).Count() 返回 0 却没报错（忘了传地址）。
Where 条件写在 Model() 前后会影响 SQL 的 FROM 子句
Model() 决定查哪张表，它必须出现在条件之前，否则 GORM 可能推导出错表或触发隐式 JOIN，导致 count 结果偏大或 SQL 报错。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确：先
Model(&User{})，再Where、Joins - ❌ 错误：先
Where("user_id = ?", id)再Model(&Order{})—— GORM 可能仍按User表生成 COUNT，但 WHERE 里用了user_id字段，字段不存在就报错
使用场景举例：统计某个用户下的订单数，必须显式指定 Model(&Order{})，不能依赖上一个查询的上下文。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
带 Joins 的 Count 容易漏掉 Count(1) 或引发笛卡尔积
如果用了 Joins()（比如查用户 + 订单 + 商品），默认 Count() 会统计 JOIN 后的行数，不是“用户数”或“订单数”，而是匹配组合数 —— 一个用户有 3 个订单，就会算成 3 行，count 得到 3，而非用户数 1。
想统计主表记录数，必须显式用 Count("DISTINCT users.id") 或更稳妥地改用子查询：
db.Table("users").
Select("COUNT(DISTINCT users.id)").
Joins("left join orders on orders.user_id = users.id").
Where("orders.status = ?", "paid").
Scan(&count)
性能影响：带 DISTINCT 的 COUNT 在大数据量下可能变慢；MySQL 8.0+ 对 COUNT(DISTINCT x) 有优化，但 PostgreSQL 需注意索引覆盖。
Count() 不走缓存，也不受 Preload 影响
有人以为 Preload("Orders") 后再 Count() 能复用关联数据，其实完全无关 —— Count() 总是发起全新 SELECT COUNT(...) 查询，忽略所有 Preload 和关联字段设置。
容易踩的坑：
- 在事务里反复调用
Count()但没注意隔离级别，读到未提交数据 - 用
db.Unscoped().Count()统计软删除数据时，忘记Unscoped()也影响后续所有操作，应限定作用域 - 并发高频调用
Count()（如限流判断）可能成为数据库压力点，考虑加 Redis 缓存或用近似统计（如pg_stat_all_tables）
真正要小心的是：你以为在“查缓存”，其实每次都在打数据库；你以为在“查关联”，其实 Count() 根本不看关联定义。
