GORM的Where链是条件累积而非动态SQL模板，每次调用追加WHERE子句且nil安全；Or/Not不重置条件，易致优先级错误；复杂依赖需子查询或Scopes封装。
Where 链是条件累积，不是动态 SQL 模板
GORM 没有“动态 SQL 构建”接口，Where 调用只是往查询条件里追加子句，且对 nil 安全：传 nil 或空值会自动跳过，不会生成 WHERE name = NULL 这类错误 SQL。
常见错误现象：db.Where("name = ?", name).Where("status = ?", status).Find(&users) 中，若 name == ""，仍会生成 WHERE name = '' AND status = 1，结果为空或不符合预期。
- 正确做法是显式判断：用
if name != "" { db = db.Where("name LIKE ?", "%"+name+"%") } - 或用
map[string]interface{}过滤空值：db.Where(map[string]interface{}{"status": status})（但注意 map 不支持 LIKE、!= 等操作符） -
Or和Not不重置前序条件，只是追加 OR/NOT 块，容易写出WHERE a=1 OR b=2 AND c=3这类优先级混乱的 SQL；建议用Scopes封装复合逻辑
子查询才是处理「依赖另一结果集」的唯一干净解法
当主表过滤条件依赖另一个独立查询结果（比如“从未登录的用户”“销售额超平均值的销售员”），Where 链和 Joins 都无法表达，必须用子查询。
典型错误直觉：“我 Joins 了 orders 表，再加个 WHERE orders.status = 'paid' 就行”——但如果需求是“只查最近 7 天有 ≥2 笔已支付订单的用户”，Join 后无法直接分组计数再过滤用户。
- 安全写法只有两种：
db.Where("id IN ?", db.Table("logs").Select("user_id").Where("action = ?", "login"))，或封装进Scopes - 禁用字符串拼接子查询，如
"id IN (SELECT ...)"，否则绕过参数绑定，引发 SQL 注入 - 性能警告：
IN/NOT IN子查询在结果集大时可能触发全表扫描；PostgreSQL 更严格，务必用EXPLAIN验证执行计划
联合查询中用游标分页替代 Offset+Limit
多表 Joins + Offset 分页必翻车：要么漏数据，要么性能崩盘。根本原因是 OFFSET 是全表级代价，且 Find 会忽略关联表字段，导致结构体字段全为零值。
正确路径是「游标分页 + 显式 SELECT + Scan」：
- 首次请求：
db.Table("users").Select("users.*, profiles.name as profile_name").Joins("LEFT JOIN profiles ON users.id = profiles.user_id").Order("users.id ASC").Limit(20).Scan(&results) - 后续请求：
db.Table("users").Select("users.*, profiles.name as profile_name").Joins("LEFT JOIN profiles ON users.id = profiles.user_id").Where("users.id > ?", lastID).Order("users.id ASC").Limit(20).Scan(&results) - 排序字段必须有索引；若用
created_at，高并发下需加id作为第二排序字段兜底，避免时间相同导致游标偏移错位 - 前端必须透传
last_id，后端不做任何转换；若last_id为空或非法，应返回400 Bad Request
Scan 接收联合结果时字段名必须完全匹配
Scan 不走 GORM 模型映射，而是按 SQL 列顺序硬填结构体字段。列名不匹配、顺序错一位，对应字段就永远是零值，且无任何报错提示。
- 结构体字段名必须与
SELECT中的别名**完全一致（大小写敏感）**，例如SELECT users.id AS user_id→ 结构体字段需为UserID uint `gorm:"column:user_id"` - 不能依赖嵌套结构体自动解包，比如
User User `gorm:"embedded"`在Scan下无效；必须平铺字段：UserID uint,UserEmail string -
Preload和Joins的语义完全不同：Joins只生成 SQL，不填充嵌套切片；想填满Orders []Order，必须用Preload
Scan 的字段名匹配规则和游标分页中排序字段的索引要求——这两处出错，连日志都看不出问题，只会静默返回空数据。 
