Go中防SQL注入唯一靠谱的方式是参数化查询，必须用于所有用户输入的值；结构部分（如ORDER BY、表名）需白名单校验，Scan需严格匹配类型与顺序。
Go 里防 SQL 注入，**唯一靠谱的方式就是参数化查询**——不是“尽量用”，是“必须用”，而且得用对地方。拼字符串、转义单引号、删分号，全都没用；ORM 也不能自动兜底，尤其你写原生 SQL 的时候。
db.Query / db.Exec 必须带占位符，不能拼字符串
用户输入一旦进 SQL 字符串，就等于把数据库的控制权交出去了。哪怕只是 WHERE status = 'active'，只要这个 active 来自 URL 参数或表单，就必须走参数化。
- ✅ 正确：
db.Query("SELECT * FROM users WHERE email = ? AND deleted = ?", email, false)（MySQL/SQLite） - ✅ 正确：
db.Query("SELECT * FROM users WHERE email = $1 AND deleted = $2", email, false)（PostgreSQL） - ❌ 危险：
db.Query("SELECT * FROM users WHERE email = '" + email + "'") - ❌ 更危险：
fmt.Sprintf("SELECT * FROM users WHERE email = '%s'", email)—— 看似加了引号，但email是"admin' -- "就直接注释掉后面逻辑
database/sql 不解析 SQL，只原样发给驱动。你拼出来的字符串，数据库就照单全收。
ORDER BY / LIMIT / 表名 / 列名不能用 ? 或 $1
SQL 标准规定：这些属于查询“结构”，不是“值”，参数化机制根本不支持绑定。试图 db.Query("ORDER BY ?", "name") 会直接 panic：sql: expected 0 arguments, got 1。
立即学习“go语言免费学习笔记（深入）”；
- 必须用白名单校验后拼接，比如排序字段只允许
"name"、"created_at"、"id" - 方向只允许
"ASC"或"DESC"，且要strings.ToUpper()统一后比对 - 表名同理：
isValidTable := map[string]bool{"users": true, "orders": true}，不在里面就拒掉 - 别信“我用
strings.Replace(email, "'", "''", -1)就安全了”——绕过方式太多，Unicode、多字节编码、驱动差异都能打穿
Scan 时类型和顺序错位，不是注入，但一样致命
Scan 不查字段名，只按 SELECT 后的列位置和类型硬匹配。表结构一变，代码没同步，轻则数据错位，重则 panic：sql: Scan error on column index 2: unsupported Scan, storing driver.Value type <nil> into type *string</nil>。
- ✅ 用具名变量：
err := row.Scan(&u.ID, &u.Name, &u.Email) - ✅ 遇到可能为 NULL 的字段，必须用
sql.NullString、sql.NullInt64等类型接收 - ❌ 别堆匿名变量：
row.Scan(&id, &name, &email)—— 人眼难对齐，改表后极易漏 - ❌ 用普通
string接 NULL 值，运行时报错，服务可能挂掉
最常被忽略的一点：白名单不是“加个 if 判断”就完事，它得覆盖所有动态拼接的结构部分——包括 JOIN 的表名、GROUP BY 的字段、甚至 WITH 子句里的 CTE 名。而参数化只保值，不保结构。这两块不分开管，防注入就是纸上谈兵。
