Golang用GORM查询记录，First和Find教程

本文深入解析了GORM中First与Find方法的核心差异与实战陷阱：First在查不到记录时返回gorm.ErrRecordNotFound而非nil，必须用errors.Is显式判断，且需传入单结构体地址并配合Order明确排序意图；Find则要求切片地址，类型传错将导致静默失败或内存错误；二者Where链式调用逻辑一致，但First自动加LIMIT 1，性能更优且语义更清晰；软删除场景下First默认过滤已删记录，手动添加deleted_at条件反而引发冲突，应善用Unscoped()精准控制。这些看似细微的差异，恰恰是日常开发中panic频发、数据错乱的根源所在。

First查不到记录时返回什么

默认情况下，First查不到数据会返回 gorm.ErrRecordNotFound 错误，而不是 nil。很多人直接判 err == nil 就认为查到了，结果后续对空结构体字段取值 panic。

• 必须显式检查错误类型：errors.Is(err, gorm.ErrRecordNotFound)
• 如果只关心是否存在，用 Limit(1).Select("id").Find(&id) 避免全字段加载
• First 默认按主键升序取第一条，不加 Order 时行为依赖表结构，别假设“最新一条”

Find和First在切片/指针上的区别

Find 要求传入切片地址（如 &users），First 要求传入单个结构体地址（如 &user）。传错类型不会编译报错，但运行时 GORM 会静默失败或填充错误内存。

• Find(&users) → 正确：users 是 []User 类型
• Find(users) 或 Find(&user) → 错误：GORM 不报错，但 users 为空或内容混乱
• First(&user) → 正确：user 是 User 类型
• First(&users) → 错误：可能 panic 或写坏内存

Where条件后跟 First 和 Find 的行为差异

两者都支持链式调用 Where，但底层 SQL 生成逻辑一致，区别只在结果处理方式——First 加了 LIMIT 1，Find 没加。

• 性能上，First 在命中第一条后就停止扫描，大数据量时更省；Find 会拉全量再截断（除非你手动 Limit(1)）
• 如果 WHERE 条件可能匹配多条，又只想取一条，优先用 First + Order 明确意图，比如 Order("created_at DESC").First(&user)
• 注意：MySQL 8.0+ 对 LIMIT + ORDER BY 有索引优化要求，没建好索引时 First 未必比 Find 快

软删除场景下 First 可能“漏掉”有效记录

开启软删除（即模型含 DeletedAt 字段）后，GORM 默认自动过滤已软删记录。但如果你手动写了 Where("deleted_at IS NULL")，又同时用了软删除，会导致条件重复或冲突。

• 确认是否启用了软删除：db.Unscoped().First(&user) 可查到软删记录
• 想查“未软删且满足其他条件”的记录，别再手动加 Where("deleted_at IS NULL")，GORM 已内置处理
• 如果模型没定义 DeletedAt 却用了 Unscoped()，GORM 会忽略它，不报错也不生效

实际写的时候最容易卡在错误判断和参数类型上，尤其是从 Find 切换到 First 时少改一个 & 符号，或者忘了处理 ErrRecordNotFound，后面读字段就崩了。

好了，本文到此结束，带大家了解了《Golang用GORM查询记录，First和Find教程》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！