子查询必须用subquery构造，禁止拼接字符串；正确做法是构建子查询对象后用where("id in (?)", subquery)；复用时封装为scope函数；preload不解决子查询过滤问题；注意mysql/postgresql性能差异；复杂条件优先用scopes封装。
子查询必须用 SubQuery 构造，不能拼字符串
直接写 Where("id IN (SELECT user_id FROM logs WHERE ...)", args...) 是高危操作——它绕过参数绑定，args 不会被转义，SQL 注入风险拉满。GORM v2 明确不支持这种原始子查询字符串注入。
正确做法是把子查询先建为独立对象：
- 用
db.Table("logs").Select("user_id").Where(...).Group(...).Having(...)构建子查询对象 - 主查询中用
Where("id IN (?)", subQuery)，括号(?)是关键，告诉 GORM 这里要嵌入子查询而非普通值 - 若子查询需复用（如多处判断“是否为活跃用户”），封装成
func(*gorm.DB) *gorm.DB类型的 scope，内部统一构造并注入
Preload 不解决子查询依赖问题，别混用
有人试图用 Preload("Logins") 加载关联日志，再在内存里过滤“从未登录的用户”——这会导致全表加载 + Go 层遍历，数据量稍大就 OOM。子查询的典型场景（如 NOT IN (SELECT user_id FROM logs)）本质是数据库层的集合运算，和预加载无关。
真正该用 Preload 的是：需要返回主表+关联表字段、且关联关系明确（如 User 有 Orders 外键）。而子查询用于条件过滤，两者职责分离：
-
Preload控制“查哪些字段”，影响 SELECT 列表 -
SubQuery控制“查哪些行”，影响 WHERE 条件 - 强行把子查询逻辑塞进
Preload会触发 N+1 或无效 JOIN，执行计划崩坏
子查询性能陷阱：MySQL 和 PostgreSQL 行为不同
WHERE id IN (?) 类子查询在 MySQL 中常被优化器自动转成 SEMI-JOIN，但 PostgreSQL 更保守，容易退化为对主表每行都执行一次子查询（即 correlated subquery），导致全表扫描。
验证方式只有 EXPLAIN：
- MySQL：看执行计划里有没有
select_type=DEPENDENT SUBQUERY，有则危险 - PostgreSQL：关注
SubPlan出现次数，若与主表行数一致，说明未去相关化 - 优化方向：子查询结果集小时可加索引（如
logs(user_id, created_at)）；大结果集时改用JOIN+GROUP BY+HAVING替代
复杂嵌套条件优先用 Scopes 封装，别堆 Where
当一个业务规则涉及多个子查询组合（如“销售额超平均值 且 所属部门近30天无投诉 且 本人未被标记高危”），硬写链式 Where().Where().Where() 会迅速失控，逻辑分散、无法复用、调试困难。
用 Scopes 把每个子查询条件封装成函数：
- 每个 scope 接收
*gorm.DB，返回新*gorm.DB，内部调用Where("id IN (?)", subQuery) - 主查询写成
db.Scopes(WithHighSales(), WithCleanDept(), WithNormalRisk()).Find(&users) - 测试时可单独调用某个 scope 查看生成 SQL，隔离验证逻辑
嵌套层级深、条件耦合紧的地方，scope 是唯一能保持可读性和可维护性的做法。别指望靠注释或文档来解释一堆 Where 调用的先后顺序和语义依赖。
