级联删除不生效需检查GORM的DeleteHooks和数据库外键ON DELETE CASCADE设置；软删除需db.Unscoped().Delete()物理删除才触发外键级联；GORM v1.25+默认关闭DeleteHooks，需显式启用并配合BeforeDelete回调实现手动级联。
级联删除不生效？先检查 GORM 的 DeleteHooks 和外键约束
Gin 本身不处理数据库级联逻辑，真正起作用的是 GORM 的软删除配置和数据库外键的 ON DELETE CASCADE 设置。如果调用 db.Delete() 后关联记录还在，大概率是这两处没对齐。
常见错误现象：DELETE FROM users WHERE id = ? 执行了，但 posts 表里对应 user_id 的记录没删；或者删了但报错 ERROR: update or delete on table "users" violates foreign key constraint。
- 确认数据库建表时外键是否加了
ON DELETE CASCADE（PostgreSQL/MySQL 都支持，但默认不启用） - 若用 GORM 的
SoftDelete（即带DeletedAt字段），db.Unscoped().Delete()才会物理删除，且不会触发外键级联 —— 此时级联必须靠数据库层保障 - GORM v1.25+ 默认关闭
DeleteHooks，如需在 Go 层拦截删除并手动清理关联，得显式开启：db.Session(&gorm.Session{AllowGlobalUpdate: true}).Delete(&user)不够，要配合BeforeDelete回调
用 BeforeDelete 回调手动实现级联逻辑
当无法修改数据库外键（比如只读权限、云数据库限制），或需要在删除前做校验/日志/异步通知时，GORM 的钩子函数更可控。
注意：回调只在 db.Delete() 或 db.Unscoped().Delete() 中触发，db.Where().Delete() 不会调用钩子（GORM 认为这是批量操作，跳过模型生命周期）。
- 在模型结构体上定义
BeforeDelete(tx *gorm.DB) error方法，例如：func (u *User) BeforeDelete(tx *gorm.DB) error { return tx.Unscoped().Where("user_id = ?", u.ID).Delete(&Post{}).Error } - 若关联表也有钩子（比如
Post删除前要清空附件），确保它们不会形成循环调用 - 钩子内务必用
tx.Unscoped()，否则软删除字段会干扰条件匹配
Gin 路由中怎么安全触发级联删除？别直接传 ID 硬删
用户请求 DELETE /api/users/123 时，不能只查 ID 就删 —— 得先验证权限、检查依赖、再执行删除链。Gin 层负责编排，不是甩给 GORM 一删了之。
- 用
db.Preload("Posts").First(&user, id)预加载关键关联，避免 N+1，也方便做业务判断（比如“该用户还有 5 篇未审核文章，禁止删除”） - 删除前加事务：
tx := db.Begin(); defer func() { if r := recover(); r != nil { tx.Rollback() } }()，确保主表和关联表操作原子性 - 不要在 Gin handler 里裸写
db.Delete(&User{ID: id})—— 这会绕过所有钩子和预检查，且无法返回具体失败原因（比如外键冲突 vs 权限不足）
一对多 vs 多对多：级联方式完全不同
HasMany 关系（如 User → Posts）适合用外键级联或 BeforeDelete；但 ManyToMany（如 User ↔ Roles）中间表没有 GORM 模型，GORM 不会自动清理。
- 对于多对多，必须显式删中间表记录：
db.Table("user_roles").Where("user_id = ?", userID).Delete(nil) - 如果中间表有额外字段（如
created_at,role_type），就不能只靠外键级联，得走 GORM 查询删除 - GORM 的
AssociationAPI（如user.Association("Roles").Clear()）底层仍是发 DELETE 语句，但它会自动识别中间表名 —— 更推荐这种方式，比手写 SQL 表名更健壮
最易被忽略的点：GORM 的 Delete 默认不走事务，也不回滚关联操作；而数据库外键级联只响应物理 DELETE，对软删除无效。这两层逻辑不咬合时，数据就会不一致。
