db.Query 直接拼接字符串会导致SQL注入，因database/sql不解析SQL而原样发送；必须用db.Prepare+参数化查询，禁用MySQL客户端插值，表名/字段名等需白名单校验。
为什么 db.Query 直接拼接字符串会出事
因为 Go 的 database/sql 包本身不解析 SQL，只是把字符串原样发给数据库。你写 "SELECT * FROM users WHERE name = '" + name + "'"，攻击者传入 name = "admin' -- "，最终执行的就是 SELECT * FROM users WHERE name = 'admin' -- '——注释掉后续校验逻辑，直接越权。
这不是 Go 特有漏洞，但 Go 默认不拦截这种拼接，开发者容易误以为“没用 ORM 就安全”。
- 所有用户输入（
http.Request.FormValue、json.Unmarshal解析的字段、URL 参数）都算不可信输入 -
fmt.Sprintf、strings.Replace、+拼接 SQL 字符串，一律禁止 - 即使加了单引号、转义引号（
strings.Replace(name, "'", "''", -1)），也防不住 Unicode 绕过或数据库特定行为
必须用 db.Prepare + stmt.Exec/stmt.Query
预编译语句把 SQL 结构和参数分离：数据库先解析语法、生成执行计划，再把参数按类型绑定进占位符。参数永远不会被当 SQL 解析，天然免疫注入。
注意：不是所有 Prepare 调用都生效——有些驱动（如 sqlite3）在连接池里复用 stmt，而 mysql 驱动默认开启 interpolateParams=true 时可能退化为客户端拼接（需关掉）。
立即学习“go语言免费学习笔记（深入）”；
- MySQL 驱动要显式禁用客户端插值：
db, _ := sql.Open("mysql", "user:pass@/dbname?interpolateParams=false") - PostgreSQL 驱动（
lib/pq）只支持$1,$2占位符，不支持? - SQLite3 驱动支持
?和$1，但Prepare后必须调用Close()或让defer stmt.Close()管理生命周期，否则连接池可能卡住
示例正确写法：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
stmt, err := db.Prepare("SELECT id, name FROM users WHERE age > ? AND status = ?")
if err != nil {
log.Fatal(err)
}
defer stmt.Close()
rows, err := stmt.Query(18, "active") // 参数类型自动匹配，不拼字符串哪些地方容易漏掉预编译
最常翻车的是动态字段名、表名、ORDER BY 子句——这些不能用 ? 占位，因为预编译只允许参数化值，不允许参数化标识符。
比如 SELECT * FROM ? 或 ORDER BY ? 会直接 panic 报错 sql: expected 0 arguments, got 1。
- 表名/字段名必须白名单校验：
if !isValidTableName(table) { return errors.New("invalid table") } - 排序字段限定为几个固定值：
switch sortField { case "created_at", "name", "score": ... } - IN 子句参数个数不确定？不能写
WHERE id IN (?)，得动态生成WHERE id IN (?, ?, ?)再stmt.Query(ids...)
性能与连接池的隐含代价
Prepare 不是免费的——它会在数据库端创建执行计划并缓存，同时在 Go 连接池里维护 stmt 对象。高频短连接场景（如 Lambda 函数）可能比直接 Query 更慢，因为每次都要重 Prepare。
但绝大多数 Web 服务用长连接，Prepare 复用率高，反而更快（省去语法解析+优化步骤）。
- 别在 handler 里每次请求都
db.Prepare，应提前在init()或启动时准备好，复用 stmt - 如果业务需要大量不同 SQL（比如报表模块有 50+ 查询模板），考虑用
sync.Pool管理 stmt，避免 GC 压力 - MySQL 5.7+ 默认
prepared_stmt_cache_size=32，超限会踢出旧 stmt；若观察到Com_prepare_sql持续上升，说明缓存不够或 stmt 泄漏
真正难的从来不是写对一行 stmt.Query，而是想清楚哪部分必须静态、哪部分能参数化、以及谁来为那几个不能参数化的字符串兜底校验。
