Count 不能与 Limit/Offset 同链使用，因其会复用全部条件（含 Limit/Offset），导致统计结果错误；正确做法是拆分独立 db 实例或用 Session 创建干净上下文。
Count(&total) 为什么不能和 Limit/Offset 写在同一个 db 链上
GORM 的 Count 方法会复用当前 *gorm.DB 实例链上已设置的所有条件，包括 Limit 和 Offset。这意味着 db.Where("status = ?", "active").Limit(20).Offset(100).Count(&total) 实际执行的是带 LIMIT 20 OFFSET 100 的 COUNT 查询——结果永远 ≤20，不是真实总数。
这不是 bug，是 GORM v2 的明确行为设计：Count 不是“算全量”，而是“算当前查询上下文下的行数”。常见错误现象是返回 total=0 或 total=20，但实际表里有上万条匹配记录。
- 正确做法是拆成两个独立的
*gorm.DB实例：一个专用于 Count，一个专用于 Find - 用
db.Session(&gorm.Session{NewDB: true})创建干净会话，避免条件污染 - 复杂场景（含
Joins、Preload）必须手写子查询，否则 Count 会忽略 JOIN 条件，导致总数虚高
Order() 缺失时 Count 和分页结果为何不一致
没加 Order() 的分页本身就不稳定，而 Count 更隐蔽地放大这个问题：数据库对无序结果集的物理存储顺序不可控，Count(*) 统计的是满足 WHERE 条件的全部行，但 Limit/Offset 取出的却是某次随机排序下的片段。两者根本不在同一逻辑序列上。
例如 db.Where("age > 18").Count(&total) 返回 5000，但 db.Where("age > 18").Limit(10).Find(&users) 可能每次返回不同 10 条——因为没指定按什么排，数据库可能按主键、按插入顺序、甚至按缓存块顺序返回。
- 必须显式写
Order("id ASC")或Order("created_at DESC, id DESC")，让 Count 和分页共享同一排序基准 - 单用
Order("status ASC")不行：status 值重复太多，排序结果不确定，Count 算的是“所有 status=active 的行”，而分页取的可能是其中任意 10 行 - 时间字段慎用
Order("created_at DESC")：毫秒级重复时，数据库内部排序仍可能抖动，补上id DESC才真正唯一
Preload 关联查询下 Count 为什么总是不准
Preload 是 GORM 的 N+1 优化手段，但它只影响 Find 主查询的结果组装，对 Count 完全无感。db.Preload("Orders").Where("users.status = ?", "active").Count(&total) 仍只查 users 表，不会管 Orders 表里有没有匹配数据。
典型陷阱：你想查“状态为 active 且至少有一个已完成订单的用户”，用了 Preload("Orders", func(db *gorm.DB) { return db.Where("status = ?", "done") })，但 Count 仍统计所有 active 用户，总数远大于实际返回的用户数。
- Count 必须和 Preload 的语义对齐：如果业务逻辑依赖关联数据存在，Count 就得改用 JOIN 子查询
- 示例：用
db.Raw("SELECT COUNT(DISTINCT u.id) FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = ? AND o.status = ?", "active", "done").Scan(&total) - 别指望
Preload能让 Count 自动感知关联过滤——它俩在 GORM 底层走的是完全不同的 SQL 构建路径
游标分页场景下还用 Count 吗
游标分页（如 WHERE id > ? ORDER BY id LIMIT 20）天然不依赖页码和总页数，所以多数情况下不该再查 Count。强行加总数，反而暴露数据规模、增加慢查询风险，还可能因并发写入导致“总数刚查完就失效”。
真实接口中，前端无限滚动只需知道“是否还有下一页”，而不是“一共有多少页”。查 Count 在这里既无业务价值，又拖累性能。
- 更轻量的做法：查
LIMIT 21，如果结果长度 == 21，就删掉最后一条、设has_next = true；否则has_next = false - 大数据量下，COUNT(*) 即使有索引也需全索引扫描，而
LIMIT 21是常数级响应 - 如果业务硬要总数（如管理后台），请单独提供 /count 接口，不要和列表接口耦合，避免缓存污染和权限混淆
Count 和分页不是一对自动协同的搭档，它们各自独立构建 SQL，共享的只有你手动传进去的 WHERE 条件。最容易被忽略的点是：Order 字段不一致、Preload 不参与 Count、以及把 Count 当成“分页上下文里的总数”来用——这三处错，会让分页接口在数据量稍大或并发稍高时， quietly 返回错误结果。 
