只要不用字符串拼接构造SQL，仅通过Query/Exec等方法传参，Go中SQL注入就基本不可能发生；占位符仅保值不保结构，表名、字段名、ORDER BY等必须白名单校验。
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。
- 排序字段必须白名单校验：
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。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 所有可能为 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 片段没走白名单或硬编码映射，前面所有防护就形同虚设。
