GORM多条件动态拼接需用变量承接链式调用，如tx := db；各条件独立判断（name非空才加WHERE），避免空字符串导致LIKE '%%'拖慢查询、绕过索引；必须显式Order排序且校验page/size，总数查询须用新Session隔离防止Limit/Offset污染。
多条件动态拼接用 Where 链式调用
条件不是固定的，而是根据请求参数有选择地加——比如前端传了 name 就查姓名，传了 city 就加城市过滤，没传就不加。GORM 本身不支持“条件为空就跳过”，得靠变量承接链式调用结果。
常见错误是直接写 db.Where("name LIKE ?", "%"+name+"%").Where("city = ?", city).Find(&users)，一旦 name 为空字符串，SQL 变成 WHERE name LIKE '%%'，看似无害，实则可能拖慢查询、绕过索引，还暴露业务逻辑（比如让人知道空 name 是合法条件）。
- 先初始化一个
*gorm.DB变量，比如tx := db - 每个条件单独判断：
if name != "" { tx = tx.Where("name LIKE ?", "%"+name+"%") } - 字符串模糊匹配建议用
LIKE而非ILIKE（PostgreSQL）或全文索引（除非真有性能需求），避免跨数据库兼容问题 - 数值类条件（如
status）别用字符串拼接，直接tx = tx.Where("status = ?", status)，防止类型转换失败 - 时间范围用
Between更安全：tx = tx.Where("created_at BETWEEN ? AND ?", start, end)
分页必须显式 Order + 校验 page/size
只写 Limit 和 Offset 不够，不加 Order 的分页在并发写入时大概率漏数据或重复——这不是 bug，是 SQL 标准行为。MySQL 和 PostgreSQL 都不保证无序结果集的行序稳定。
另一个高频坑是把前端传来的 page 和 size 直接喂给 Offset 和 Limit，没做任何校验。比如 page=0 导致 Offset(-10) panic，size=10000 触发慢查询甚至 DB 连接池耗尽。
-
Order必须写，且优先用主键或带时间戳+主键的组合：.Order("created_at DESC, id DESC")，避免仅用created_at（时间相同则排序不确定） -
page小于 1 时强制设为 1：if page -
size超过上限（如 100）就截断：if size > 100 { size = 100 }，别依赖前端自律 - 计算
Offset时用(page - 1) * size，注意整型溢出风险（大页码 × 大 size 可能超 int64）
总数查询不能复用同一个 db 实例
db.Where(...).Limit(size).Offset(offset).Count(&total) 查出来的 total 永远 ≤ size，因为 Count 会继承前面链上的 Limit 和 Offset。这是 GORM v2 的明确行为，不是误用，但极易踩中。
更隐蔽的问题是：如果分页主查询用了 Preload 或 Joins，总数查询若不隔离上下文，可能因关联字段缺失导致 COUNT 结果不准（比如 LEFT JOIN 后 WHERE 条件过滤了主表字段，COUNT 却算的是 JOIN 前的行数）。
- 最简方案：用新 session 隔离：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 复杂关联场景（如带
Joins("Profile")），手写子查询更可控：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u LEFT JOIN profiles p ON u.id = p.user_id WHERE ...) t").Scan(&total) - 别在事务里连续执行 Count + Find，两次查询之间若数据变更，总数和当前页数据对不上是常态，业务上可接受就不用强一致
模糊查询性能要靠索引兜底
LIKE "%keyword%" 是典型的索引失效操作，尤其当字段没建全文索引或 keyword 很短时，全表扫描不可避免。GORM 层再怎么优化拼接逻辑也救不了。
容易被忽略的一点是：即使你写了 Order("created_at DESC")，如果 WHERE 条件字段没进联合索引，MySQL 仍可能放弃使用该索引，转而走 filesort + 全表扫描。
- 给常用模糊查询字段建前缀索引（如
name(191)），而非全字段索引，节省空间 - 联合索引顺序很重要：查询条件字段放前面，排序字段放后面，例如
INDEX idx_name_status_created (name, status, created_at) - 测试执行计划：
EXPLAIN SELECT * FROM users WHERE name LIKE '%foo%' ORDER BY created_at DESC，确认是否用到索引 - 真有高并发全文检索需求，别硬扛，该上 Elasticsearch 或 PgSQL 的
tsvector就上
动态条件 + 分页 + 模糊查询三者叠加时，最容易被绕过的其实是 ORDER BY 的稳定性与索引覆盖的完整性。这两点不落实，其他所有链式拼接、参数校验都只是在给雪球打蜡。
