GORM v2中Or条件最稳妥写法是Where起头后紧跟Or链式调用，避免中间插入其他条件；复杂逻辑需用map、struct或Scope封装；NULL判断必须显式写IS NULL；Or易致全表扫描，应建复合索引或改用Union。
Or条件在GORM v2中用Where+Or链式调用最稳妥
GORM v2不支持直接在Where里写原生OR逻辑（比如"name = ? OR age > ?"）而不加括号保护，容易被后续And条件污染。正确做法是用Where起头，再接Or——它会自动把前一个条件和当前条件用OR连接，并保持逻辑组层级清晰。
常见错误是写成db.Where("name = ?", "a").Or("age > ?", 18).Find(&users)，看起来没问题，但一旦中间插入Where或Joins，生成SQL可能意外变成AND主导。所以务必让Or紧跟在第一个Where之后，中间不要穿插其他条件方法。
- ✅ 推荐写法：
db.Where("name = ?", "Alice").Or("name = ?", "Bob").Find(&users) - ❌ 危险写法：
db.Where("status = ?", "active").Or("name = ?", "Alice").Where("age > ?", 18)（最后的Where会变成AND，破坏原本OR意图） - ⚠️ 注意：多个
Or连续调用时，GORM默认左结合，等价于(A OR B) OR C，不是A OR (B OR C)——但语义一致，可放心用
复杂Or组合必须用map或struct配合Scopes隔离
当Or条件涉及不同字段、嵌套逻辑（比如(name = ? AND status = ?) OR (email LIKE ?)），单靠链式Or无法表达。这时得用Where传入map或匿名struct，GORM会自动展开为OR条件组；更安全的做法是封装进Scope函数，避免和其他查询混用。
例如查“已激活用户”或“邮箱以gmail开头的用户”，不能写Where("status = 'active').Or("email LIKE ?", "%@gmail.com")——因为status是字符串字面量，没参数化，易SQL注入。应该：
- 用
map[string]interface{}：db.Where(map[string]interface{}{"status": "active", "email": map[string]interface{}{"LIKE": "%@gmail.com"}}).Find(&users)（⚠️注意：GORM对map中LIKE的支持依赖数据库驱动，MySQL可用，SQLite可能不认） - 更通用：写
Scope函数：func ActiveOrGmail(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "active").Or("email LIKE ?", "%@gmail.com") } // 调用 db.Scopes(ActiveOrGmail).Find(&users)
Or与NULL判断组合时要小心IS NULL语法
GORM对NULL值的处理很特殊：Where("field IS NULL")能正常工作，但Where("field = ?", nil)会被忽略，Where("field = ?", sql.NullString{})也不触发IS NULL。如果想写name = ? OR phone IS NULL，必须显式写出IS NULL片段，不能依赖参数传nil。
- ✅ 正确：
db.Where("name = ?", "Tom").Or("phone IS NULL").Find(&users) - ❌ 无效：
db.Where("name = ?", "Tom").Or("phone = ?", nil).Find(&users)（GORM直接跳过该Or子句） - ? 小技巧：用
clause.IsNil可适配多种数据库，但需import"gorm.io/gorm/clause"，且仅适用于字段本身为nil判断，不适用于OR分支中的独立IS NULL
性能隐患：Or条件常导致全表扫描，记得加复合索引
数据库看到OR往往放弃使用索引，尤其当各分支字段无联合索引时。比如WHERE name = ? OR email = ?，即使name和email各自有索引，MySQL也可能走全表扫描。
- 优化方向：为常用Or组合建复合索引，如
INDEX idx_name_email (name, email)（注意顺序，覆盖最常单独查的字段） - 验证方式：用
EXPLAIN看执行计划，确认type是否为ref或range，而非ALL - 替代思路：真有性能瓶颈时，考虑拆成两个
UNION查询（GORM支持Union方法），让每个分支走独立索引
Or不是语法糖，它是查询逻辑的转折点。写的时候多看一眼生成的SQL，别只信链式调用的表面顺序。
