因为GORM对字符串参数的处理逻辑不同：用“?”占位会走预处理路径实现参数化，而字符串拼接则直接嵌入SQL导致注入或解析错误；字段名和操作符必须白名单校验。
动态拼接 SQL 时为什么 Where 和 Order 参数必须用问号占位？
因为 GORM 的 Where、Order、Limit 等方法对字符串参数的处理逻辑不同：当传入字符串 + 可变参数（如 Where("name = ?", name)）时，GORM 会走预处理路径，把值绑定为参数；但如果写成 Where("name = " + name) 或 Where("name = '" + name + "'")，就直接拼进 SQL，完全绕过参数化，等于裸奔。
常见错误现象：name 是用户输入的 O'Reilly，拼接后变成 name = 'O'Reilly'，SQL 解析失败或被注入。
- ✅ 正确写法：
db.Where("name = ?", name).Find(&users) - ❌ 危险写法：
db.Where("name = '" + name + "'").Find(&users) - ⚠️ 注意：
Where("name = ? AND age > ?", name, age)中的?个数必须与后续参数严格匹配，否则 GORM 会静默忽略多余参数或 panic
如何安全地构建条件可变的查询（比如搜索字段不确定）？
不能靠字符串拼接字段名或操作符，因为它们无法参数化。GORM 提供了 map[string]interface{} 和结构体两种安全方式，但字段名仍需白名单校验。
使用场景：前端传 filter[field]=name&filter[operator]=like&filter[value]=go，后端要动态生成 WHERE 条件。
立即学习“go语言免费学习笔记（深入）”；
- 字段名（如
name、email）必须从预设白名单中取，禁止直接使用用户输入：allowedFields := map[string]bool{"name": true, "email": true} - 操作符也需限制：
allowedOps := map[string]bool{"=": true, "LIKE": true, ">=": true} - 值部分始终用
?占位：db.Where(field+" "+op, value).Find(&results) - 更稳妥的做法是用
map[string]interface{}：db.Where(map[string]interface{}{"name": name, "status": "active"}).Find(&u)—— GORM 内部自动转成参数化语句
Scopes 和 func(*gorm.DB) *gorm.DB 能否防注入？
能，但前提是 scope 函数内部不拼接 SQL 字符串。Scope 本质是链式调用的封装，安全性取决于你写的函数体。
错误示范：func NameLike(name string) func(*gorm.DB) *gorm.DB { return func(db *gorm.DB) *gorm.DB { return db.Where("name LIKE '%" + name + "%") } } —— 这里又拼了字符串。
- ✅ 安全写法：
return db.Where("name LIKE ?", "%"+name+"%") - ✅ 更推荐用
Clause或Expression封装复杂逻辑，例如自定义Like表达式：db.Where(clause.Like{Column: clause.Column{Name: "name"}, Value: name}) - ⚠️ 注意：
Raw()和Exec()是高危接口，一旦用到就必须手动校验所有输入，且尽量避免在业务逻辑中出现
为什么 Find(&v, id) 比 First(&v, "id = ?", id) 更安全？
两者都安全，但语义和隐含风险不同。Find(&v, id) 是主键查找，GORM 明确知道这是按主键查，会走优化路径并强制类型检查；而 First(&v, "id = ?", id) 虽然用了参数化，但字符串部分仍是手写的 SQL 片段，容易误写成 "id = " + id。
- 主键查找优先用
Find()或First()带整型参数：db.First(&user, 123)—— GORM 自动转成WHERE id = ? - 非主键字段查找必须用
?占位，且避免在条件字符串里混入变量：db.Where("status = ? AND created_at > ?", status, time.Now().Add(-24*time.Hour)).Find(&logs) - 性能提示：大量使用
Where链式调用不会额外解析 SQL，GORM 是延迟构建，但过度嵌套 scope 可能增加调试难度
真正容易被忽略的是字段名和操作符的校验——参数化只保值安全，不保结构安全。哪怕所有 ? 都用对了，只要让用户控制了 ORDER BY 后面的字段名，照样能注入。所以白名单不是可选项，是必选项。
