go中防sql注入的关键是将用户输入作为参数传入而非拼接sql，db.query与db.prepare防注入效果相同，因驱动均分离sql模板与参数；表名列名等结构部分须白名单校验，scan需严格匹配字段顺序、类型及null处理。
database/sql 的预处理机制本身不防注入，真正起作用的是你是否把用户输入当值传、而不是当 SQL 片段拼。只要用对占位符（? 或 $1），哪怕不用 Prepare，Query 和 Exec 也一样安全。
为什么 db.Query("...", arg) 和 db.Prepare(...).Query(arg) 防注入效果完全一样
两者都依赖驱动在底层将参数值与 SQL 模板分离发送，数据库解析阶段根本看不到用户输入——它只看到“一条带占位符的语句 + 一组独立参数”。攻击者无法改变语法结构，只能影响值。
-
db.Query每次调用都会走一次预编译流程，多数驱动（如go-sql-driver/mysql）会自动缓存执行计划，实际性能差异极小 -
db.Prepare显式复用预编译语句，适合高频固定结构查询（比如每秒上千次的用户 ID 查询） - 别为了“看起来更安全”硬套
Prepare：短生命周期连接、低频查询下，它反而增加开销；更危险的是，有人误以为“用了 Prepare 就万事大吉”，结果在Prepare前就拼了表名
ORDER BY / LIMIT / 表名这些地方不能用 ?，但很多人还是栽在这儿
SQL 标准规定：占位符只允许出现在值的位置（WHERE 右侧、IN 列表、函数参数等），不允许出现在标识符或子句关键字位置。试图写 ORDER BY ? 会直接 panic：sql: expected 0 arguments, got 1。
- 常见翻车写法：
fmt.Sprintf("ORDER BY %s DESC", input)—— 这等于把门焊死又留个狗洞 - 正确做法是白名单校验：
map[string]bool{"created_at": true, "name": true, "score": true}，不在其中就拒掉 - 排序方向同理：
if sortDir != "ASC" && sortDir != "DESC" { return err }，别信strings.ToUpper后直接拼 - 表名映射必须显式，比如
switch tenantID { case "prod": table = "users_prod" }，而非"users_" + tenantID
Scan 接收时出错不是注入，但会让服务挂得比注入还快
Scan 不参与防注入，但它错配类型或忽略 NULL 会导致 panic 或数据错位，间接暴露结构、引发逻辑异常，甚至被用来探测字段是否存在。
- 遇到可能为
NULL的字段，必须用sql.NullString、sql.NullInt64等类型接收，普通string直接扫NULL会 panic：sql: Scan error on column index 0: unsupported Scan, storing driver.Value type <nil> into type *string</nil> - 结构体字段名要和
SELECT列顺序/别名严格对应；SELECT id, name AS username就得配Username string，否则扫错列，恶意输入可能被当数据用 - 别堆匿名变量：
row.Scan(&id, &name, &email)—— 改表加字段后极易漏，人眼难对齐
最常被忽略的一点：白名单只校验输入，不校验映射逻辑本身。比如你写了 if validFields[input] { query += " ORDER BY " + input }，但忘了 input 可能含换行或注释符，那白名单就形同虚设。校验之后还得做基础清洗，比如 strings.TrimSpace 和拒绝非 ASCII 字符。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
