gorm delete未删除数据最常见原因是未传主键或未指定条件，因默认仅对带有效主键的结构体执行按主键删除，否则静默跳过；需确认id非零、显式where、或用unscoped物理删除。
Go 中用 GORM 调用 Delete 为什么没删掉数据？
最常见原因是没传主键或没指定条件，GORM 默认只对带主键值的结构体执行“按主键删除”，否则会静默跳过。比如：db.Delete(&User{}) 不会删任何记录，哪怕 User 表里有数据。
实操建议：
- 确认是否传了带有效
ID的实例：db.Delete(&User{ID: 123}) - 想按其他字段删，必须显式加
Where：db.Where("status = ?", "inactive").Delete(&User{}) - 别依赖结构体零值字段——
db.Delete(&User{Name: "foo"})不会按Name删，除非你额外Where - 注意软删除：如果模型嵌入了
gorm.Model或定义了DeletedAt字段，Delete默认是软删（设DeletedAt），不是物理删除
Delete 的三种调用方式和对应行为差异
GORM 的 Delete 看似一个函数，实际根据参数类型走完全不同逻辑路径，容易误用。
实操建议：
- 传指针结构体 + 主键非零 → 按主键物理删（软删开启时例外）：
db.Delete(&User{ID: 456}) - 传指针结构体 + 主键为零 → 不删，也不报错，返回
RowsAffected == 0 - 传空结构体指针 +
Where→ 按条件删（可多行）：db.Where("age > ?", 60).Delete(&User{}) - 传具体类型（如
*User）但不传实例 → 报错：invalid argument, need pointer to struct
软删除场景下，怎么真正物理删除？
一旦模型包含 DeletedAt gorm.DeletedAt 字段，所有 Delete 都自动转成更新 DeletedAt，这是 GORM v2 的默认行为。想绕过它，得明确告诉 GORM “这次我要硬删”。
实操建议：
- 用
Unscoped()强制忽略软删除逻辑：db.Unscoped().Delete(&User{ID: 789}) - 或者在
Where中显式排除软删标记：db.Where("deleted_at IS NULL AND status = ?", "spam").Delete(&User{}) - 注意：
Unscoped会影响后续链式调用，比如db.Unscoped().Where(...).Delete(...)全部不受软删限制 - 物理删除后，关联的
HasOne/HasMany不会自动级联删，需手动处理或配foreignKey约束
批量删除时 RowsAffected 返回值不准？
MySQL 下用 DELETE FROM ... WHERE ... 本身能返回准确影响行数，但 GORM 在某些配置下（比如用了连接池、事务未提交、驱动版本低）可能返回 -1 或 0，尤其在 Where + Delete 组合中。
实操建议：
- 检查
db.Error是否为nil，比依赖RowsAffected更可靠 - 需要精确计数时，先
SELECT COUNT(*)再删，避免误判 - 用
db.Session(&gorm.Session{DryRun: true})预演 SQL，确认生成的语句是否符合预期 - SQLite 驱动对
RowsAffected支持更弱，生产环境慎用批量删+计数断言
软删除开关、主键存在性、Unscoped 的作用域——这三个点串起来，基本覆盖了 90% 的 Delete 失效场景。漏掉任意一个，都可能让代码看起来“执行了却没效果”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
