gorm中记录不存在时err非nil但属正常控制流，应使用errors.is(err, gorm.errrecordnotfound)判断；需关闭日志刷屏、注意软删除影响，并避免误用find替代first。
First/Take/Last 查询不到时，err 不是 nil，但不等于失败
很多人看到 err != nil 就 panic 或打 error 日志，结果发现“查不到用户”这种业务常态被当成故障告警了。GORM 把记录不存在（gorm.ErrRecordNotFound）当作一种**可预期的控制流分支**，不是异常。它返回的 err 是一个具体值，不是底层连接中断或 SQL 语法错那种真错误。
-
errors.Is(err, gorm.ErrRecordNotFound)是唯一推荐的判断方式（Go 1.13+） - 别用
err == gorm.ErrRecordNotFound—— 虽然多数情况能过，但某些封装层会 wrap 错误，导致判断失效 - 别漏掉其他错误：比如表名写错、字段不存在、权限不足，这些 err 也非 nil，但
errors.Is(..., gorm.ErrRecordNotFound)为 false，必须单独处理（如记录日志、触发告警）
Logger 配置里关掉 record not found 的日志刷屏
默认情况下，每次 First 查不到都会在日志里打印一行 record not found，QPS 高时日志直接被刷爆。这不是 bug，是设计行为——但生产环境必须关。
- 初始化
*gorm.DB时，在logger.Config中设IgnoreRecordNotFoundError: true - 这个开关只影响日志输出，**完全不影响 err 的返回值和判断逻辑**
- 如果用了自定义 logger（比如写入文件或发到 Loki），确保该配置透传到每个 session，否则中间件或事务里可能又冒出日志
软删除场景下，ErrRecordNotFound 可能被“掩盖”
模型含 DeletedAt 字段且启用了软删除时，First 查不到记录，err 仍是 gorm.ErrRecordNotFound，但你未必真没数据——它可能只是被软删了。
- 想确认是不是软删导致的：用
db.Unscoped().First(&user)绕过过滤再试一次 - 如果
Unscoped().First成功，说明数据存在但已被软删；此时 err 类型不变，但语义变了，业务需按软删逻辑走（比如返回“账号已注销”） - 别在 Where 条件里手动加
deleted_at IS NULL—— GORM 已自动处理，重复加会导致 SQL 错误或索引失效
用 Find + 切片替代 First 时，error 行为完全不同
有人改用 Find(&users)（users []User）来规避 ErrRecordNotFound，确实能让 err == nil，但代价是语义丢失和潜在风险。
-
Find查不到时返回空切片，err == nil，靠len(users) == 0判断，看似简单，但无法区分“真没数据”和“数据库连不上”（后者 err 也可能为 nil？不，这时 err 才是非 nil） - 更危险的是：如果本意是查单条，却误传了
&user（单结构体）给Find，GORM 不报错，但行为未定义——可能 panic，也可能静默填充错误内存 - 真正需要“是否存在”的场景，不如用
Limit(1).Select("id").Find(&id)，只查主键，省 IO，err 判断逻辑也一致
errors.Is(err, gorm.ErrRecordNotFound) 只出现在某一层，它得贯穿整个数据访问路径。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
