Go语言SQL注入防护方法_Golang数据库安全编程指南-Golang-PHP中文网

只要不用字符串拼接构造sql，仅通过query/exec等方法传参，go中sql注入就基本不可能发生；占位符仅保值不保结构，表名、字段名、order by等必须白名单校验。

go语言sql注入防护方法_golang数据库安全编程指南

database/sql 包本身不防注入，但只要你不用字符串拼接构造 SQL，只通过 Query、Exec、QueryRow 等方法传参，SQL 注入在 Go 里就基本不可能发生——这不是“大概率安全”，而是底层驱动把参数值和 SQL 模板完全隔离的结果。

用 `Query` 和 `Exec` 时必须带占位符，别拼字符串

Go 里 95% 的 SQL 注入都源于手写 fmt.Sprintf 或 + 拼接。比如："SELECT * FROM users WHERE name = '" + name + "'"，一旦 name 是 "admin' -- "，整条查询逻辑就被绕过。

MySQL/SQLite 驱动用 ? 占位符：db.Query("SELECT * FROM users WHERE id = ? AND status = ?", id, status)
PostgreSQL 驱动用 $1、$2：db.Query("SELECT * FROM users WHERE id = $1 AND status = $2", id, status)
混用会直接报错：sql: expected 1 arguments, got 0 或 sql: expected 0 arguments, got 1
IN 子句要传 slice，GORM 会自动展开；原生 database/sql 不支持单个 ? 绑定多个值，得手动拼占位符串或改用 sqlx.In

`ORDER BY`、表名、字段名不能用 `?` 或 `$1`

SQL 标准规定：这些属于查询结构，不是运行时值，数据库根本不允许参数化绑定。写 db.Query("ORDER BY ?", "name") 会 panic：sql: expected 0 arguments, got 1。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

排序字段必须白名单校验：map[string]bool{"created_at": true, "score": true, "name": true}
表名映射建议用常量+switch，比如输入 "prod" → 查 "users_prod"，而不是 "users_" + input
排序方向（ASC/DESC）也得白名单，不能直接拼："ORDER BY " + field + " " + dir
别信 strings.ReplaceAll(input, "'", "") 这类过滤——Unicode 空格、/**/ 注释、换行都能绕过

`Scan` 不防注入，但类型错位一样致命

Scan 只按 SELECT 列顺序和类型硬匹配，不看字段名。表结构一变、代码没同步，轻则数据错位，重则 panic：sql: Scan error on column index 0: unsupported Scan, storing driver.Value type <nil> into type *string</nil>。

所有可能为 NULL 的字段，必须用 sql.NullString、sql.NullInt64 等接收，不能直接用 string
结构体字段名要和 SELECT 别名严格一致，比如 SELECT name AS username 就得对应 Username string
避免匿名变量扫描：row.Scan(&id, &name, &email) —— 改表后极易漏对齐，人眼难维护
sql.RawBytes 是读二进制字段用的，不是“绕过参数化”的工具；拿它拼 SQL 和字符串拼接没区别

ORM 如 GORM 的 `Raw` 方法不自动防护

GORM 默认开启 PrepareStmt，Where("name = ?", name) 是安全的；但一旦你调用 Raw，防护就交还给你自己。

db.Raw("SELECT * FROM " + tableName + " WHERE id = ?", id) —— 表名未校验，照样中招
正确替代：db.Table(tableName).Where("id = ?", id).Find(&u)，前提是 tableName 来自枚举或配置项
泛型 GORM（gorm.G[User]）能强制模型与查询绑定，类型错直接编译失败，但要求 GORM >= v1.30.0
GEN 自动生成的 query 方法，连字段名拼错都会编译报错，适合高安全要求场景，但自定义 SQL 必须写在 doc comment 里才被识别

最易被忽略的是：占位符只保“值”，不保“结构”。哪怕你每个 WHERE 条件都用了 ?，只要表名、排序字段、UNION 结构、JSON 中嵌套的 SQL 片段没走白名单或硬编码映射，前面所有防护就形同虚设。