count不准根源是gorm的count()不继承joins/preload，只认where和模型定义；修复需用newdb:true隔离链式状态或手写子查询。
多表JOIN后Count总数不准的根源
用 db.Joins("LEFT JOIN profiles ON users.id = profiles.user_id").Where("profiles.active", true) 查用户列表时，如果直接 db.Model(&User{}).Count(&total)，结果会漏掉 JOIN 和 WHERE 条件，算的是全表用户数，不是“已激活 profile 的用户数”。GORM 的 Count() 不继承 Joins 或 Preload，只认 Where 和模型定义。
- 简单修复：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Joins("LEFT JOIN profiles ON users.id = profiles.user_id").Where("profiles.active", true).Count(&total)，靠NewDB: true隔离链式状态 - 复杂场景（含多级 JOIN 或 GROUP BY）：手写子查询更可靠，例如
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u LEFT JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) AS t", true).Scan(&total) - 别在事务里反复调
Count+Find—— 两次查询之间若数据变更，总数和当前页数据可能对不上
Preload一对多导致N+1或数据膨胀
写 db.Preload("Orders").Joins("LEFT JOIN profiles...") 看似省事，但 GORM 会先查出 10 个用户，再为每个用户发一条 SELECT * FROM orders WHERE user_id = ?，实际加载的订单远超 10 条；若 Orders 表有百万行，内存和 DB 压力直接飙升。
- 只取关联字段？改用
Joins+Select：构造type UserWithOrderAmt struct{ UserName string; OrderAmt float64 }，然后db.Table("users").Select("users.name, orders.amount").Joins("LEFT JOIN orders...").Scan(&results) - 要完整 Order 结构但限制数量？不能靠
Preload实现“每个用户只取最新 3 个”，得拆成两步：先查用户 ID 列表 → 拼IN子句批量查 Order，并加ORDER BY created_at DESC+LIMIT 3（需手写子查询或窗口函数） - 别在分页主查询里嵌套
Preload("Orders.Products")—— 关联层级越深，笛卡尔积风险越高
游标分页在多表场景下怎么写才不丢数据
传统 OFFSET 在 JOIN 后更不可靠：排序字段若来自右表（如 profiles.updated_at），同一 user.id 可能对应多条 profile，ORDER BY profiles.updated_at DESC, users.id DESC 排序结果不稳定，翻页时容易重复或跳过。
- 游标必须基于确定性、单调、有索引的字段 —— 优先用左表主键
users.id，次选带id兜底的组合，例如ORDER BY users.created_at DESC, users.id DESC - WHERE 条件要严格匹配排序字段：若排序是
ORDER BY users.id ASC，游标条件就是WHERE users.id > ?；若排序含profiles.active，则 WHERE 必须包含该过滤条件，否则索引失效 - 首次请求不能省略
ORDER BY，后续请求的last_id必须来自上一页最后一条记录的users.id字段值，前端透传，后端不做任何转换
大结果集分页时内存和性能怎么控住
查 50 万用户时用 db.Find(&users)，GORM 会把全部记录反射进内存，结构体字段越多、关联越深，GC 压力越大 —— 我们线上曾因此触发 2GB 内存占用和 OOM。
- 分页必须搭配
Select()：只取接口需要的字段，例如db.Select("id,name,email,created_at").Limit(...).Offset(...)，减少网络传输和内存拷贝 - 导出类场景别用
Find，改用Rows()流式读取：rows, _ := db.Table("users").Select("...").Rows(); defer rows.Close()，逐行 Scan，内存恒定 - 每页 size 硬限制在 1–100，超出截断；page 小于 1 强制设为 1；避免前端传
page_size=10000直接打穿 DB 连接池
游标分页不是加个 WHERE 就完事，它要求排序字段在所有 JOIN 表中都有明确、稳定、可索引的映射关系。很多团队卡在这一步，不是因为不会写 SQL，而是没意识到多表下“最后一条记录的 id”到底该取哪张表的哪个字段。
