正确做法是用 query/exec 参数化传参防注入，禁用字符串拼接；占位符因驱动而异（mysql用?，postgres用$1）；动态表名等须白名单校验；预处理提升性能但非必需，orm亦需规范用法。
用 database/sql 的 Query 和 Exec 传参，别拼字符串
Go 里 SQL 注入的根源几乎全是手动拼接 SQL 字符串，比如 "SELECT * FROM users WHERE id = " + userID。只要用户控制 userID，就能塞进 1 OR 1=1 -- 这类 payload。
正确做法是把变量当参数传给 Query 或 Exec，让驱动自动处理转义和类型绑定：
rows, err := db.Query("SELECT name FROM users WHERE age > ?", age)
注意：不同驱动占位符不同——mysql 用 ?，postgres 用 $1，sqlite 两者都支持但推荐 ?。混用会导致 sql: expected 1 arguments, got 0 这类错误。
- 永远别用
fmt.Sprintf或+拼 SQL - 如果必须动态拼表名或字段名（如分表查询），只能白名单校验，不能靠参数化
-
Scan不防注入，它只读结果；防护发生在执行前
警惕 sql.RawBytes 和 sql.NullString 的误用场景
这些类型本身不引发注入，但常出现在“以为安全了”的错觉里。比如有人把用户输入先塞进 sql.NullString，再拼进 SQL，以为加了包装就没事——其实没用，拼接时照样裸奔。
更隐蔽的是日志或调试中打印原始 SQL：log.Printf("executing: %s", query)，如果 query 是拼出来的，日志就成了注入入口（尤其配合远程日志系统时）。
-
sql.NullString只解决空值映射问题，不参与 SQL 构建 - 所有日志里的 SQL 必须确认来自预编译语句，或已手动过滤/脱敏
- 用
db.QueryRow().Scan()时，参数仍需走问号占位符，不是用了Scan就自动安全
预处理语句（Prepare）不是银弹，但能堵住某些边界漏洞
预处理在服务端提前编译 SQL 模板，客户端只传参数值，理论上杜绝语法层面的注入。但 Go 的 database/sql 默认开启连接池复用预处理语句，而某些驱动（如旧版 go-sql-driver/mysql）在连接断开后未自动重准备，可能触发 stmt is closed 错误。
实际建议：对高频、固定结构的查询（如登录校验、ID 查询）显式用 db.Prepare，但别为了“更安全”强行全量预处理——普通 Query 已足够防注入，预处理主要价值在性能。
- 预处理不能防止表名/列名/ORDER BY 子句的注入，这些仍需白名单
- PostgreSQL 驱动默认强制预处理，MySQL 驱动需加
parseTime=true&loc=Local等参数才稳定支持 - 短生命周期 HTTP handler 中，直接
db.Query比反复Prepare/Close更轻量
ORM 如 gorm 或 sqlc 的坑比你想象的多
很多人以为 ORM 天然免疫 SQL 注入，结果栽在 Where("name = '" + name + "'") 或 Session().Select("id, " + userField) 这类写法上。GORM 的 Where 方法接受两种签名：Where("age > ?", 18) 安全，Where("age > " + str) 危险。
sqlc 因为生成的是纯 database/sql 代码，只要模板里没用 {{.arg}} 拼接，就基本安全；但它不拦着你在 Go 层自己拼 SQL。
- GORM 的
Scopes和Joins如果传入用户输入的字段名，一样会出事 - 用
sqlc时，检查生成的.sql文件是否含$$或:占位符，没有就说明模板被硬编码了 - 任何 ORM 的
Raw/Exec方法都是注入高发区，盯紧参数传递方式
真正难防的从来不是标准 CRUD，而是动态排序、条件聚合、权限字段拼接这类需求——它们逼你靠近 SQL 边界，这时候白名单校验比任何框架特性都管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
