gorm 不拦截全表 delete 是因设计上默认不校验 where 条件有效性，需通过 beforedelete hook 拦截无效条件、sql 审核中间件兜底及 ci 规范卡点三重防御。
全表 DELETE 为什么 GORM 不拦，而你必须自己拦
GORM 的 Delete 方法默认不校验 WHERE 条件是否有效——和 Update 一样，它只看结构体主键字段（如 ID）是否为零值。若传入一个 ID 为 0 的 struct，或直接调用 db.Delete(&User{})，GORM 会静默生成 DELETE FROM users，全表清空。
这不是 bug，是设计选择：GORM 把“是否允许无条件操作”的决策权交给业务层。但生产环境里，没人想靠“靠人不靠机制”来防删库。
-
Delete不像First或Find那样强制要求条件；它甚至接受Where("1=1")这类恒真表达式，且不报错 - 批量删除（
db.Where("status = ?", "draft").Delete(&User{})）看似安全，但若Where被漏写、被覆盖（比如中间件重置了Statement），就退化为全表删 -
Unscoped().Delete更危险：它绕过软删除标记，且同样不检查 WHERE
用 BeforeDelete Hook 拦住无效 WHERE
Hook 是最贴近 GORM 执行链的防御点，但不能只查 SQL 字符串里有没有 WHERE 关键字——要判断 WHERE 是否“有效”。
以下逻辑必须在 BeforeDelete 中实现：
- 提取
db.Statement.SQL.String()，若为空或不含WHERE，直接db.AddError(errors.New("unsafe DELETE: missing WHERE")) - 排除恒真条件：
WHERE 1=1、WHERE true、WHERE id IS NOT NULL（尤其当id无索引时等效全表扫描） - 只接受含参数占位符的条件：
WHERE id = ?、WHERE email = ? AND tenant_id = ? - 对
db.Delete(&u)形式，额外检查u.ID是否非零；若为零，拒绝执行（避免依赖隐式主键行为）
示例片段：
db.Callback().Delete().Before("gorm:delete").Register("check-delete-where", func(db *gorm.DB) {
if db.Statement.SQL.String() == "" {
return
}
sql := db.Statement.SQL.String()
if strings.Contains(sql, "WHERE") && !isValidWhere(sql) {
db.AddError(errors.New("unsafe DELETE: trivial or missing WHERE clause"))
}
// 额外检查 struct 主键
if reflect.ValueOf(db.Statement.ReflectValue.Interface()).Kind() == reflect.Ptr {
v := reflect.Indirect(reflect.ValueOf(db.Statement.ReflectValue.Interface()))
if v.Kind() == reflect.Struct {
idField := v.FieldByName("ID")
if idField.IsValid() && idField.Kind() == reflect.Uint && idField.Uint() == 0 {
db.AddError(errors.New("unsafe DELETE: zero-value primary key"))
}
}
}
})
SQL 审核中间件：兜底防线，覆盖 Raw/Delete 绕过场景
Hook 只管 GORM 方法，但 db.Raw("DELETE FROM users")、db.Exec("TRUNCATE TABLE users") 完全绕过它。线上必须在数据库连接层加一道硬闸。
推荐做法是包装 database/sql.Conn，拦截所有 Exec 和 Query 调用：
- 对包含
DELETE或UPDATE的语句，强制匹配正则\bWHERE\s+[^\s]+\s*=（简单但有效，比纯字符串扫描更准） - 拒绝
TRUNCATE、DROP、ALTER等 DDL 语句（除非明确白名单） - 记录并告警所有无 WHERE 的 DML，包括
DELETE FROM users和UPDATE users SET x=1 - 该中间件需注入到 GORM 的
Config.DriverName或通过gorm.Open的gorm.Config.ConnPool注入
开发规范与 CI 卡点：让误操作无法合入代码
技术手段再严，也防不住人绕过。必须把规则落到流程里：
- 禁止在业务代码中出现裸
db.Delete(&User{})或db.Unscoped().Delete；CI 检查 PR 中是否含这些字符串 - 所有删除接口必须显式接收
id参数，并用db.First(&u, id)先查再删，避免Delete直接作用于空 struct - 分页删除（如后台批量清理日志）必须走
Where("created_at ，且 <code>Limit不可省略 - 本地开发启用
GORM_DEBUG，日志里看到DELETE FROM users就立刻打断——真正的沙箱不是运行时拦住，而是让人一眼看出问题
真正难防的不是没写 WHERE，而是写了 WHERE tenant_id = ? 却忘了给 tenant_id 赋值，结果变成 WHERE tenant_id = NULL——这在 MySQL 里可能命中全部行。这类边界 case，只能靠结构体字段校验 + 日志回溯，没法靠单一机制兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
