gorm join 后 count(*) 返回膨胀行数，需用 distinct("users.id") 或子查询；offset 分页性能差，建议游标分页；joins 与 preload 混用易出错，应拆分为两步；分页元信息需手动计算且条件须严格一致。
JOIN 查询后 COUNT(*) 不等于实际分页总数
GORM 在 Joins 后直接调用 Count()，默认只统计主表行数，而 JOIN 可能一对多膨胀，导致分页总数偏大。比如 User 有多个 Order，db.Joins("JOIN orders ON users.id = orders.user_id").Count(&total) 返回的是订单数，不是用户数。
正确做法是用子查询或 Distinct() 去重主表 ID：
- 若需按主表分页（如“查带订单的用户列表”），必须加
Distinct("users.id")，再配合Count() - GORM v1.23+ 支持
Count(&total, "users.id")指定字段计数，但底层仍依赖数据库是否支持；更稳妥是手写子查询 - MySQL 下可手动构造：
db.Table("(SELECT DISTINCT users.id FROM users JOIN orders ON users.id = orders.user_id) AS t").Count(&total)
OFFSET + LIMIT 在 JOIN 场景下性能断崖式下降
当 JOIN 表数据量大、又没合适联合索引时，LIMIT 20 OFFSET 10000 会让数据库扫描前 10020 行再丢弃，JOIN 膨胀后更慢。这不是 GORM 的锅，但容易误以为是框架问题。
实操建议优先避开 OFFSET：
- 用游标分页：记录上一页最后一条的
users.id和orders.created_at，下一页查WHERE users.id > ? AND orders.created_at > ? - 若必须用 offset，确保 JOIN 条件字段（如
orders.user_id）和排序字段（如users.created_at）有联合索引 - GORM 的
Limit().Offset()不会自动优化，它只是拼 SQL —— 性能瓶颈在 SQL 设计本身
GORM Preload 与 Joins 混用导致重复数据或 panic
有人想“既要 JOIN 过滤，又要 Preload 关联数据”，于是写 db.Joins("JOIN orders...").Preload("Orders").Find(&users)。这会导致：要么 JOIN 让主表记录重复（Preload 后聚合异常），要么 GORM 内部处理冲突 panic（尤其 v1.21 之前）。
安全拆解方式：
- 过滤用
Joins+Where，查出主表 ID 列表（如[]uint） - 再用
db.Where("id IN ?", ids).Preload("Orders").Find(&users)查完整数据 - 或者改用原生 SQL 子查询：先
SELECT DISTINCT user_id FROM ... WHERE ... LIMIT ? OFFSET ?，再用结果查主表+Preload -
Preload本质是额外 N+1 查询，和Joins的单次 JOIN 查询语义不同，强行合并只会增加不可控性
分页元信息丢失：TotalPages / HasNext 等需手动计算
GORM 不提供开箱即用的分页对象（如 Page{Data, Total, Page, PageSize}）。Limit().Offset().Find() 只返回切片，Count() 得总数，其余全靠手算。
关键注意点：
-
Count()必须和主查询用完全相同的Joins、Where、Group条件，否则总数错 —— 建议把查询条件封装成函数复用 - 前端传
page=0或page=-1时，GORM 不校验，Offset(0)是合法的，但业务上可能要拦截 - 总数为 0 时，
TotalPages = 0，但HasNext = false；总数非 0 时，HasNext = (currentPage * pageSize) —— 这些逻辑得自己写，别指望 GORM 补全
复杂点在于：JOIN 分页的本质是 SQL 层问题，GORM 只是管道。你得清楚自己到底在对哪个实体分页、按什么去重、用什么排序，然后让 SQL 和代码严格对齐。漏掉一个 Distinct 或错配一个索引，线上就可能查半天返回空。
