参数化查询是防止SQL注入的唯一可靠方式，必须使用占位符（如?或$1）而非字符串拼接，动态标识符需白名单校验，禁用multiStatements，所有数据库操作应带context超时控制。
用 database/sql 的 Query 和 Exec 时必须传参，不能拼字符串
Go 标准库的 database/sql 本身不防注入——它靠的是你不用 + 拼接 SQL。一旦你写 "SELECT * FROM users WHERE name = '" + name + "'"，就等于把门敞开。
正确做法是用问号占位符（MySQL/SQLite）或 $1（PostgreSQL），让驱动在底层做参数绑定：
db.Query("SELECT * FROM users WHERE email = ?", email)常见错误现象：sql.ErrNoRows 看似正常，但实际查到了不该查的数据；或者插入时字段值被截断、多出单引号导致语法错。
- MySQL 驱动（
github.com/go-sql-driver/mysql）只认?，写$1会直接报sql: expected 0 arguments, got 1 - PostgreSQL 驱动（
github.com/lib/pq）只认$1、$2，用?会报pq: syntax error at or near "?" - 哪怕只是查固定值，比如
"WHERE status = 'active'"，如果这个值来自用户输入（如 URL 查询参数），也必须走参数化
别信 fmt.Sprintf 或 strings.Replace 能“过滤”SQL注入
有人试过对输入做 strings.Replace(email, "'", "''", -1) 或删掉分号，这完全无效。SQL 注入不是靠单引号“破坏字符串”，而是靠改变查询结构——比如把 admin 变成 admin' -- 或 admin' OR '1'='1，绕过认证逻辑。
立即学习“go语言免费学习笔记（深入）”；
更危险的是，某些数据库支持多语句执行（MySQL 默认开启），用 ; 分隔就能一条命令干两件事。而 database/sql 的 Exec 默认只执行一条，但如果你用了 mysql.ParseDSN 并手动加了 multiStatements=true，那 email 里塞 admin'; DROP TABLE users; -- 就真能删表。
- 永远不要自己实现“转义函数”，标准驱动已内置安全绑定
- 检查 DSN 是否含
multiStatements=true，生产环境务必设为false（默认就是false，除非显式开启） - 日志里打印 SQL 时，别直接打原始 SQL 字符串——要打参数化后的模板，否则会误以为“没拼接就安全”
Scan 和 StructScan 不解决注入，只管结果解析
有人觉得“我用 sqlx.StructScan 或 rows.Scan(&id, &name) 就算用了安全方式”，这是误解。这些函数只负责把查询结果映射到变量，和 SQL 构造完全无关。注入发生在 Query 那一刻，不是 Scan 时。
典型误用场景：动态表名或列名。参数化只支持值（WHERE 条件、INSERT 值），不支持标识符（表名、字段名、ORDER BY 后的列）。这时候不能靠参数占位，得靠白名单校验：
allowedTables := map[string]bool{"users": true, "orders": true}
if !allowedTables[table] {
return errors.New("invalid table name")
}-
sql.Named只是命名参数语法糖，底层仍是位置绑定，不提升安全性 - ORM 如
gorm默认开启参数化，但它的Where("name = ?", name)安全，Where("name = " + name)一样危险 - 用
fmt.Sprintf拼ORDER BY %s是高频雷区，必须严格限制可选字段
用 context.Context 控制查询生命周期，避免因超时导致连接堆积
这不是直接防注入，但和安全强相关：没有上下文控制的长查询，可能被恶意构造的慢 SQL（如 WHERE id IN (SELECT ...) 套多层子查询）拖垮数据库连接池，间接放大攻击面。
所有 Query、Exec、Prepare 都该带 context：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() rows, err := db.QueryContext(ctx, "SELECT * FROM logs WHERE level = ?", level)
- 超时设太短（如 100ms）会导致正常查询频繁失败；太长（如 30s）会让连接卡住，压垮 DB
- PostgreSQL 的
statement_timeout是服务端兜底，但 Go 层先超时更可控 - HTTP handler 中用
r.Context()而不是context.Background()，保证请求取消时 DB 操作同步中断
参数化是唯一可靠防线，其余都是辅助。最常被忽略的点：动态 SQL 片段（表名、排序字段、条件组合）没法参数化，必须用白名单或预定义枚举，而不是“过滤一下就上”。
