gorm中查不到数据时需用errors.is(err, gorm.errrecordnotfound)判断，first()是唯一可靠的存在性检查方式，且应加order by；take()无序不可用于判空；first+create非原子操作易致重复插入，推荐唯一索引配合onconflict或on duplicate key update。
查不到数据时直接 panic 或忽略错误，是 GORM 项目中最容易被线上日志淹没的隐患。GORM 不会把 ErrRecordNotFound 当成异常抛出，它只是普通 error，必须显式判断。
First() 返回 gorm.ErrRecordNotFound 是唯一可靠的存在性判断方式
很多人误以为 Take() 更轻量就用它做“是否存在”检查，结果在 WHERE 条件不匹配时仍返回第一条记录 + nil 错误，逻辑彻底错乱。
-
First()一定加ORDER BY id ASC，哪怕没写条件——它语义就是“取主键最小的那条”，适合查首条、最早创建等场景 -
Take()完全无序，db.Where("name = ?", "xxx").Take(&u)可能返回任意一条记录，根本不能用于判空 - 只有
errors.Is(err, gorm.ErrRecordNotFound)才能安全确认“真没找到”，别用err == nil或err != nil做分支
别在事务里用 First() 后直接 Create()，小心幻读和竞态
常见伪代码：db.First(&u, "email = ?", email); if errors.Is(err, gorm.ErrRecordNotFound) { db.Create(&User{Email: email}) }——这在并发下可能插入重复 email。
- 这段逻辑不是原子的：两次 DB 调用之间存在时间窗口，另一个请求可能已插入同 email
- 正确做法是用唯一索引 +
db.Clauses(clause.OnConflict{DoNothing: true}).Create()（PostgreSQL）或ON DUPLICATE KEY UPDATE（MySQL） - 如果必须用 First+Create，得套在事务里，并确保隔离级别足够（如
RepeatableRead），但性能代价高，不推荐
全局封装 FindOrZero 时，务必保留原始 error 类型
有人喜欢写工具函数如 FindOrZero(db, &u, "id = ?", id) 并默认返回零值，这会让调用方彻底丢失“到底是没查到，还是查到但字段全零”的上下文。
- 零值掩盖问题：比如
User{ID: 0, Name: "", Age: 0}可能是未初始化，也可能是真实数据 - 更安全的做法是返回
(User, error)二元组，让调用方自己决定怎么处理gorm.ErrRecordNotFound - 如果一定要封装，至少提供
FindOrError()和FindOrDefault()两个版本，命名即契约
最常被忽略的一点：GORM 的 ErrRecordNotFound 是一个变量，不是类型，所以必须用 errors.Is() 判断，不能用 ==；另外，它只由 First()、Last()、Take() 等单条查询函数返回，Find() 即使结果为空 slice，error 也是 nil。
