not条件查不到预期记录，因gorm对struct中零值字段（如age:0）自动忽略，仅生成非零字段的!=条件；空slice会导致全表扫描；not与where默认and连接，不支持or或嵌套逻辑。
Not条件查不到预期记录？先确认字段是否为零值
GORM 的 Not 方法对 struct 传参有隐式过滤逻辑：它只会把非零值字段转成 != 条件。比如 User{Name: "jinzhu", Age: 0}，实际生成的 SQL 是 WHERE name != 'jinzhu'，Age: 0 被完全忽略——这常导致你以为“排除了年龄为 0 的用户”，其实根本没生效。
解决办法很简单：
- 用 map 或字符串条件显式控制字段，例如
db.Not(map[string]interface{}{"name": "jinzhu", "age": 0}).Find(&users) - 或改用字符串写法：
db.Not("age = ?", 0).Find(&users) - 避免混用 struct 和业务语义上的“零值含义”，比如 age=0 在业务中可能代表“未填写”，但 GORM 不认这个逻辑
Not + IN 查询要小心空 slice
当你写 db.Not("name", []string{}).Find(&users)，GORM 会生成全表扫描 SQL：SELECT * FROM users（即不加 WHERE）。这不是 bug，是设计行为：空 slice 被解释为“无需排除任何值”。但线上误传空参数时极易引发慢查询甚至 OOM。
实操建议：
- 在调用前做防御性判断：
if len(names) > 0 { db.Not("name", names).Find(&users) } - 用
db.Where("name NOT IN (?)", names)替代（需自行处理空 slice） - 注意 MySQL 对
NOT IN (NULL)的语义陷阱：只要子查询含 NULL，整条 NOT IN 判定为 FALSE，结果为空——GORM 不自动规避这点
Not 和 Where 混用时的优先级陷阱
Not 不是独立子句，它和 Where 共享同一层 WHERE 条件，且 GORM 默认用 AND 连接。例如：
db.Where("status = ?", "active").Not("name", "admin").Find(&users)
等价于 WHERE status = 'active' AND name != 'admin'，不是你想的“排除所有 name=admin 的 active 记录”以外的全部记录。
如果真需要 OR 逻辑或括号分组，必须用原生 SQL：
db.Where("status = ? AND NOT (name = ?)", "active", "admin").Find(&users)- 或更清晰地：
db.Where("status = ? AND name != ?", "active", "admin").Find(&users) - 别依赖
Not做复杂布尔组合，它不支持嵌套、括号或 OR
Not 对主键切片的特殊行为
传入主键 slice 时，db.Not([]int64{1,2,3}).First(&user) 会生成 WHERE id NOT IN (1,2,3)，看起来没问题。但有两个隐藏风险：
- 如果 slice 长度超 MySQL max_allowed_packet（默认 4MB），会导致查询失败，错误信息类似
MySQL server has gone away - 当主键类型是 uint、string 或 UUID 时，必须确保 slice 类型严格匹配模型定义，否则 GORM 可能静默忽略或 panic
- 对大表慎用
NOT IN，MySQL 5.7+ 优化器对它的执行计划常不如LEFT JOIN + IS NULL高效
真正难搞的从来不是语法怎么写，而是你传进去的那个 slice 到底有没有被截断、类型对不对、数据库能不能扛住——这些点在线上一出问题，日志里几乎不报错，只表现为你“查不到数据”。
