gorm 的 crud 方法（如 create、save、delete 等）均返回一个 *gorm.db 实例，其 error 字段承载操作结果状态；忽略该字段将导致错误静默失败，必须显式检查才能实现健壮的错误处理。
gorm 的 crud 方法（如 create、save、delete 等）均返回一个 *gorm.db 实例，其 error 字段承载操作结果状态；忽略该字段将导致错误静默失败，必须显式检查才能实现健壮的错误处理。
在使用 GORM 进行数据库操作时，一个常见误区是假设方法调用成功即代表数据已持久化——实际上，GORM 的所有核心写操作（Create、Save、Update、Delete）*均不直接返回 error 类型，而是返回 `gorm.DB指针**。该结构体内部封装了Error` 字段，用于传递执行过程中发生的错误（如约束冲突、连接中断、SQL 语法错误、事务回滚等）。若未主动检查该字段，错误将被静默吞没，极易引发难以排查的数据一致性问题。
✅ 正确的错误检测方式
所有 CRUD 方法均支持链式调用并返回可检查的 *gorm.DB，推荐以下两种安全写法：
方式一：显式接收返回值（更清晰、便于调试）
user := User{Name: "Alice", Email: "alice@example.com"}
result := db.Create(&user)
if result.Error != nil {
log.Printf("创建用户失败: %v", result.Error)
// 可进一步区分错误类型，例如：
if errors.Is(result.Error, gorm.ErrRecordNotFound) {
// 处理记录未找到逻辑
} else if strings.Contains(result.Error.Error(), "duplicate key") {
// 处理唯一键冲突
}
return result.Error
}
log.Printf("成功创建用户，ID: %d", user.ID)方式二：一行内直接检查（简洁，适合简单场景）
if err := db.Create(&user).Error; err != nil {
return fmt.Errorf("保存用户失败: %w", err)
}⚠️ 注意：db.NewRecord() 不是错误检测机制，它仅判断结构体是否具有有效主键（即是否为“新记录”），与数据库操作成败无关。它无法捕获 INSERT 失败（如外键约束、NOT NULL 违反等），切勿将其误用为错误判断依据。
? 获取更多上下文信息
除 Error 外，返回的 *gorm.DB 还提供其他诊断字段：
- RowsAffected：实际影响的行数（对 Create 通常为 1，对 Update/Delete 可用于判断是否匹配到目标记录）；
- Statement.SQL 和 Statement.Vars（需启用日志）：可用于审计原始 SQL 与参数；
- 结合 db.Debug() 临时开启详细日志，快速定位 SQL 层问题：
db.Debug().Create(&user) // 输出完整 SQL 与参数到 stdout
? 最佳实践总结
- 始终检查 .Error：任何写操作后，必须校验返回 *gorm.DB 的 Error 字段；
- 避免裸调用：禁止写 db.Create(&user) 而不处理返回值；
- 区分错误语义：使用 errors.Is() 或字符串匹配识别常见错误（如 gorm.ErrRecordNotFound、sqlite3.ErrConstraint）；
- 事务中更要谨慎：在 db.Transaction() 内部，子操作错误不会自动回滚——仍需手动检查并返回非 nil error 触发回滚；
- 升级提醒：GORM v2（gorm.io/gorm）延续相同模式，但结构体字段名保持一致（Error、RowsAffected），迁移时无需修改错误处理逻辑。
通过严格遵循这一模式，开发者能确保每个数据库写入都具备可观测性与可控性，从根本上杜绝“看似成功、实则失败”的隐蔽缺陷。
