子查询在GORM中不是语法糖，而是处理反向依赖、聚合过滤、跨表逻辑的必要手段；必须用SubQuery()构造，确保参数安全、方言适配与SQL正确性，否则易致条件失效、SQL注入或全表扫描。
子查询在 GORM 中不是语法糖，而是处理反向依赖、聚合过滤、跨表逻辑的必要手段；不按规范写，轻则条件失效，重则 SQL 注入或全表扫描。
子查询必须用 SubQuery() 构造，不能拼字符串
直接写 Where("id IN (SELECT user_id FROM logins WHERE created_at > ?)", weekAgo) 看似省事，但会绕过 GORM 的参数绑定机制——问号不会被替换，最终生成的 SQL 可能是 WHERE id IN (SELECT user_id FROM logins WHERE created_at > ?)，数据库报错或返回空结果。更危险的是，若 weekAgo 来自用户输入且未校验，拼接字符串会直接暴露 SQL 注入面。
-
SubQuery()是 GORM v2 明确要求的入口，它把子查询封装为*gorm.DB类型，确保方言适配和参数安全 - 即使子查询只有一行，也必须显式调用，比如
db.Table("logins").Select("user_id").Where(...).SubQuery() - 别信“不加也能跑”的侥幸：某些 MySQL 场景下看似成功，但在 PostgreSQL 或 SQLite 下立刻失败
Where("id IN (?)", subQuery) 的括号不能省
占位符 (?) 中的括号是强制语法，不是可选装饰。写成 Where("id IN ?", subQuery) 或 Where("id IN (?), subQuery)（少右括号）都会让 GORM 把 subQuery 当作普通值传入，最终生成类似 WHERE id IN '0xc000123456' 的非法 SQL。
- 所有子查询注入点都必须带完整括号：
NOT IN (?)、> (?)、= (?)，哪怕数据库语法本身不要求 - 复合条件如
WHERE status = 'active' AND id IN (?)，子查询仍要独立构造，不可塞进字符串里 - 如果子查询返回多列（比如
Select("user_id, ip")），而主查询只用其中一列，GORM 会报错；务必保证Select()字段数与主查询期望匹配
嵌套子查询要分步构造，别在 Scope 里新建 db
例如查“被 ≥3 个不同管理员标记为高危的用户”，需要两层：第一层按 user_id 分组计数，第二层筛选该计数 ≥3 的 user_id。常见错误是写一个 Scope 函数，在里面调用 gorm.Open() 或返回 map[string]any，导致链式中断、条件丢失。
立即学习“go语言免费学习笔记（深入）”；
- 每层子查询必须基于原始
db实例派生，例如sub1 := db.Table("flags").Group("user_id").Having("COUNT(DISTINCT admin_id) >= ?", 3) - 第二层必须复用
sub1：sub2 := db.Table("users").Where("id IN (?)", sub1) -
Scope函数只能接收和返回*gorm.DB，内部禁止新建 session、调用Preload或Joins，否则子查询上下文污染
子查询放 WHERE 还是 FROM，取决于结果集大小和数据库类型
当子查询结果超过几百行，尤其在 PostgreSQL 下，WHERE id IN (?) 容易触发全表扫描。此时应改用 FROM 子句（派生表），配合 Joins 提升可控性。
- 用
Joins("(?) AS risky ON users.id = risky.user_id", subQuery)替代Where("id IN (?)", subQuery) - 子查询中必须明确
Select("user_id")，否则派生表字段名缺失，JOIN 失败 - 执行前务必开
DryRun打印 SQL：db.Session(&gorm.Session{DryRun: true}).Where(...).Find(&[]any{})，再拿去EXPLAIN验证 - 软删除模型（含
DeletedAt）在子查询中默认被过滤，若需包含已软删记录，必须显式Unscoped()，例如db.Unscoped().Table("logins").Select("user_id")...
最容易被忽略的是子查询的执行时机——它不是惰性求值，而是在 Where 调用时就构造 SQL 片段；所以任何影响 db 实例状态的操作（比如 Session、Scopes、Preload）都必须在子查询构造前完成，否则条件漏传、索引失效、结果错乱都是静默发生的。
