Go项目中中间件无法防止SQL注入，因其作用于HTTP层而注入发生在数据库执行前；真正防护需在database/sql调用链中使用占位符、白名单校验及规范DAO层逻辑。
Go 项目里加中间件本身防不了 SQL 注入——注入发生在数据库查询执行前，而中间件通常在 HTTP 层，两者不在同一环节。真正要加固，得把防护逻辑落到 database/sql 调用链上，中间件只负责前置过滤和兜底。
中间件能做什么：只拦输入，不碰 SQL
中间件适合做请求入口的粗筛，比如校验参数格式、拒绝非法字符、限制长度，但它无法知道你后面会怎么拼 SQL。常见误用是以为加了日志中间件或参数校验中间件就“安全了”，结果 handler 里仍写 db.Query("SELECT * FROM users WHERE name = '" + name + "'")。
- 可拦截明显恶意 payload：如字符串含
UNION、SELECT、;、--、单引号嵌套等（注意：不能仅靠关键词黑名单，需结合上下文） - 对 ID 类参数强制转
int或int64，失败即拒；对用户名、邮箱等走正则白名单（如^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$） - 记录原始请求体和参数，但必须脱敏：不要
log.Printf("req: %v", r)，而要显式抹掉 password、token、raw_sql 等字段 - 别在中间件里做“SQL 拦截”：没有通用规则能判断
"user_" + tenantID是分表还是注入，这事只能由业务代码用白名单决定
真正起作用的是 database/sql + 白名单组合
SQL 注入是否发生，只取决于你调用 db.Query、db.Exec 时有没有用占位符，以及有没有把用户输入塞进表名、ORDER BY 这类结构位置。中间件插不上手，必须在 DAO 层控制。
-
WHERE、VALUES、SET后的值，一律用?（MySQL/SQLite）或$1（PostgreSQL），参数直接传变量，别转字符串再拼 -
ORDER BY字段必须查白名单：validSort := map[string]bool{"created_at": true, "score": true}，不在里面就返回 400 - 动态表名（如按租户分表）用硬编码映射：
switch tenant { case "prod": table = "users_prod" }，绝不用"users_" + tenant - IN 子句别手动拼
"id IN (1,2,3)"，用sqlx.In或 GORM 的Where("id IN ?", ids)，让框架展开占位符
GORM 场景下中间件的有限价值
GORM 本身不因中间件变安全，但中间件可以帮你发现那些绕过 ORM 规范的危险调用，比如裸用 db.Raw()。
立即学习“go语言免费学习笔记（深入）”；
- 可在中间件里统计
db.Raw调用频次，对非常规路径告警（正常业务不该高频调 Raw） - 若项目约定所有查询必须走
gorm.DB实例，可在中间件检查r.Context().Value("db")是否为 *gorm.DB，不是就记录并阻断 - 对
ctx.Value透传的 SQL 模板做简单扫描：匹配SELECT.*FROM.*[a-z_]+后接未转义变量，触发审计日志 - 别指望中间件自动重写
Where("name = '" + name + "'")——语法已错，运行时才暴露，中间件看不到 AST
最易被忽略的点是：白名单校验必须在参数绑定前完成，且校验逻辑要和实际 SQL 构建逻辑放在同一函数内。拆成“中间件校验 → handler 拼 SQL”两步，中间仍可能被篡改或绕过。安全边界不在 HTTP 入口，而在 db.Query 那一行代码之前。
