根本原因是参数化查询将用户输入与SQL结构分离，由驱动自动转义和类型绑定；错误写法直接拼接输入导致注入，正确做法是用?或$1占位符配合Query/Exec，且表名等结构部分须白名单校验。
用 database/sql 的参数化查询代替字符串拼接
SQL注入的根本原因是把用户输入直接拼进 SQL 字符串里。Golang 的 database/sql 包原生支持参数化查询，只要坚持用 ?（MySQL/SQLite）或 $1（PostgreSQL）占位符 + Query/Exec 的变参形式，就能让驱动自动转义和类型绑定。
错误写法（绝对禁止）：
username := r.URL.Query().Get("user")
query := "SELECT * FROM users WHERE name = '" + username + "'"
rows, _ := db.Query(query) // 危险！输入 'admin' OR 1=1 -- 会逃逸正确写法（必须）：
username := r.URL.Query().Get("user")
rows, err := db.Query("SELECT * FROM users WHERE name = ?", username)
if err != nil {
http.Error(w, "DB error", http.StatusInternalServerError)
return
}- 所有用户可控输入（
r.FormValue、r.URL.Query().Get、json.Unmarshal解析的字段等）都必须走参数化路径 - 不要试图自己写“过滤函数”去 strip 单引号或转义——这不可靠，且容易漏掉边界情况（如宽字节、编码绕过）
- 注意：占位符不能用于表名、列名、ORDER BY 子句等结构部分；这些需通过白名单校验 + 映射方式控制
避免使用 fmt.Sprintf 或 strings.Replace 构造查询语句
有人会想：“我用 fmt.Sprintf 拼接，再手动加引号和转义”，这是典型误区。Go 的字符串拼接无法阻止恶意输入破坏语法结构，且不同数据库转义规则不一致（如 PostgreSQL 的 $$ 块、MySQL 的反斜杠处理），手动模拟极易出错。
立即学习“go语言免费学习笔记（深入）”；
常见错误模式：
// ❌ 错误：看似加了单引号，但 username 可为 'admin' -- '
query := fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", username)
// ❌ 更危险：用 Replace 尝试“过滤”
username = strings.Replace(username, "'", "''", -1) // 仅对某些 DB 有效，且可被编码绕过
- 任何含用户输入的 SQL 片段，只要出现在
Query/Exec的第一个参数中，就必须是纯静态字符串 - 动态列名或条件逻辑，应拆成代码分支，例如：
if field == "name" { query = "SELECT * FROM users ORDER BY name" }，并限制field只能是预设的几个值 - ORM（如 GORM）也需确认是否启用参数化；GORM v2 默认开启，但若用
Session(&gorm.Session{DryRun: true})或原始 SQL 模式，仍可能绕过
使用 sql.Named 处理命名参数（尤其 PostgreSQL）
PostgreSQL 驱动（lib/pq 或 pgx）不支持 ? 占位符，而用 $1, $2 等位置参数。若逻辑复杂、参数多，易错序。此时可用 sql.Named 配合命名参数风格，提升可读性和安全性。
stmt := `SELECT * FROM users WHERE status = $1 AND created_at > $2` rows, _ := db.Query(stmt, "active", time.Now().AddDate(0, 0, -7))// 更清晰的方式（需驱动支持命名参数，如 pgx） stmtNamed :=
SELECT * FROM users WHERE status = :status AND created_at > :sincerows, _ := db.NamedQuery(stmtNamed, map[string]interface{}{ "status": "active", "since": time.Now().AddDate(0, 0, -7), })
-
sql.Named是标准库提供的兼容机制，但底层是否生效取决于 driver 实现；pgx支持完整命名参数，lib/pq仅支持位置参数 - 命名参数不会降低安全性，但能减少参数顺序错乱导致的隐性 bug（比如把时间戳传给 status 字段）
- 不要因用了命名参数就放松对输入值的校验——它只解决拼接问题，不替代业务层合法性检查（如邮箱格式、ID 是否为数字）
警惕 ORM 的原始 SQL 和钩子方法
用 GORM 或 sqlx 并不自动免疫 SQL 注入。当调用 Raw()、Exec() 原始 SQL 方法，或在 BeforeCreate 等钩子中拼接 SQL 时，风险重现。
示例（GORM 中的陷阱）：
// ❌ 危险：Raw() 内直接插值
db.Raw("SELECT * FROM users WHERE name = '" + name + "'").Find(&users)
// ✅ 安全：Raw() 也支持参数化
db.Raw("SELECT * FROM users WHERE name = ?", name).Find(&users)
// ❌ 钩子中拼接
func (u User) BeforeCreate(tx gorm.DB) error {
tx.Exec("INSERT INTO logs (msg) VALUES ('created user " + u.Name + "')") // 漏洞点
return nil
}
- GORM 的
Raw、Session、Transaction内部执行原始 SQL 时，同样必须用参数化 - 自定义钩子、中间件、审计日志记录等场景，凡涉及 SQL 构造，一律回归“静态 SQL 字符串 + 参数列表”原则
- 上线前用模糊测试工具（如
sqlmap -u "http://x/?id=1"）扫描关键接口，验证是否真无注入面
实际中最容易被忽略的是：表名和排序字段这类“元信息”输入，既不能参数化，又常被当成普通参数放行。它们必须走严格白名单，比如 map[string]bool{"name": true, "email": true, "created_at": true}，而不是简单做正则匹配。
