GORM中Select后Count不准，因Count复用Select导致SQL语法错误；必须用db.Session(&gorm.Session{NewDB: true})隔离或手写子查询，且Select须在Where/Order之后、Offset/Limit之前。
为什么用Select后分页总数查不准
直接在分页链上加 Select("id, name")，再调 Count(&total)，得到的 total 往往是 0 或错误值。因为 GORM 的 Count 默认复用前面所有链式调用的 SQL 片段，Select 会污染 COUNT 查询——它试图对 SELECT id, name 做 COUNT(*)，而数据库不允许这种混合写法。
- 必须隔离 COUNT 查询上下文：用
db.Session(&gorm.Session{NewDB: true})新建一个干净的 DB 实例 - 或者手写子查询：
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users WHERE status = ?) AS t", status).Scan(&total) - 别依赖
db.Select(...).Count()，它在绝大多数场景下不工作
Select + Offset/Limit 分页时字段顺序不能乱
Select 必须放在 Order 和 Where 之后、Offset/Limit 之前，否则排序或条件可能失效。GORM v2 虽然允许部分顺序松动，但 Select 若写在 Order 前，会导致 ORDER BY 字段不在 SELECT 列表中，PostgreSQL 直接报错，MySQL 可能静默降级为无序。
- 正确顺序：
db.Where().Order("id ASC").Select("id, name, created_at").Offset().Limit().Find(&users) - 错误写法：
db.Select("id, name").Where().Order("id ASC")...—— PostgreSQL 报ERROR: column "id" must appear in the GROUP BY clause or be used in an aggregate function - 如果用了
Preload，Select只作用于主表，关联表字段不会被限制，别指望靠它减少 JOIN 数据量
只查必要字段能缓解 OFFSET 性能衰减，但救不了根本
在百万级表上执行 Offset(100000).Limit(20)，即使 Select("id, name") 也慢——数据库仍要扫描并跳过前 10 万行。覆盖索引才是关键：确保 ORDER BY 字段（如 id）和 WHERE 条件字段都在联合索引里，避免回表。
- 例如建索引：
CREATE INDEX idx_user_status_id ON users (status, id);，配合WHERE status = ? ORDER BY id使用 -
Select("id")搭配覆盖索引，能让 MySQL 完全走索引扫描，不读数据页 - 但 OFFSET 超过 5 万后，响应延迟仍可能从 20ms 升至 800ms+，这时候该切游标分页了，不是换字段能解决的
前端传字段白名单时，Select 字符串不能直接拼接
如果允许前端指定返回字段（如 ?fields=id,name,created_at），千万别用 fmt.Sprintf("SELECT %s", fields) 拼进 SQL——这是典型的 SQL 注入温床。GORM 不校验 Select 参数，传入 id, name; DROP TABLE users 会直接执行。
- 安全做法：预定义白名单 map，比如
allowedFields := map[string]bool{"id": true, "name": true, "created_at": true} - 解析
c.Query("fields")后逐个校验，非法字段直接忽略或返回 400 - 拼
Select时用strings.Join(validFields, ", ")，不经过任何用户输入直连 - 别忘了：哪怕只选 1 个字段，
Order和Where仍需完整字段支持，比如按updated_at排序就不能删掉它
