因为 database/sql 不解析 sql，仅原样转发字符串，拼接用户输入会导致 sql 注入；必须用 prepare+query 参数化，且表名等语法结构需白名单校验。
为什么 database/sql 的 Query 和 Exec 不能直接拼接字符串
因为 Go 的 database/sql 包本身不解析 SQL，它只是把传进去的字符串原样发给数据库驱动。如果你写 db.Query("SELECT * FROM users WHERE name = '" + name + "'")，攻击者输入 O'Reilly 或更糟的 '; DROP TABLE users; --，SQL 就真会被执行。
常见错误现象：查询结果异常、返回空数据但无报错、数据库表被意外删除或篡改。
- 所有用户输入（URL 参数、表单字段、Header 值）都必须视为不可信，哪怕前端做了校验
- 字符串拼接只适用于固定结构的 SQL 片段（如硬编码的表名、列名），且必须白名单校验
- 预编译语句不是“防注入万能开关”——如果用
fmt.Sprintf拼出整个 SQL 再传给Query，照样中招
怎么用 Prepare + Query 实现安全参数化
Go 标准库通过 Stmt 对象把 SQL 模板和参数分离：数据库先编译 SQL 结构，再把参数按类型安全绑定，完全避免语法混淆。
使用场景：带 WHERE 条件的查询、INSERT/UPDATE 的值填充、LIMIT/OFFSET 动态控制（但注意：ORDER BY 列名不能参数化）。
立即学习“go语言免费学习笔记（深入）”；
示例：
stmt, _ := db.Prepare("SELECT id, name FROM users WHERE status = ? AND created_at > ?")
rows, _ := stmt.Query("active", time.Now().AddDate(0, 0, -7))- 占位符统一用
?（MySQL/SQLite 驱动），PostgreSQL 驱动用$1,$2，不能混用 -
Query和Exec接收的参数必须和?个数、顺序、类型严格匹配，否则 panic 或静默失败 - 频繁调用时复用
Stmt（Prepare后不 Close），否则每次新建 Stmt 会多一次网络 round-trip
哪些地方不能用参数化，必须手动处理
SQL 语法结构本身（如表名、列名、ORDER BY 字段、UNION 子句）无法参数化，数据库协议不支持。强行用 ? 会导致语法错误，比如 SELECT * FROM ? 直接报 ERROR 1064。
正确做法是白名单校验 + 显式映射：
validTables := map[string]bool{"users": true, "orders": true}
if !validTables[table] {
http.Error(w, "invalid table", http.StatusBadRequest)
return
}
query := "SELECT * FROM " + table + " WHERE id = ?"
db.Query(query, id)- 禁止用正则“过滤掉危险字符”，比如删掉分号或注释符——绕过方式太多（编码、嵌套、大小写混用）
- 动态构建 ORDER BY 时，只允许从预设字段列表选，不要解析用户传来的字符串内容
- 如果业务真需要任意列名，考虑用视图或存储过程封装，把动态逻辑移出应用层
为什么 Scan 出错可能掩盖注入风险
Scan 失败通常是因为类型不匹配（比如把字符串扫进 int），但若 SQL 已被注入篡改，返回的列结构可能和预期完全不同，导致 Scan panic 或静默截断数据——这时你看到的只是“类型错误”，实际漏洞早已触发。
- 始终检查
rows.Err()和scan返回的 error，不要只看nil - 开发期开启数据库日志（如 MySQL 的
general_log），确认发出去的 SQL 真的是你写的模板，而不是拼接后的变体 - 对关键操作（如资金、权限变更）加审计日志，记录原始参数和最终执行的 SQL 摘要（不含敏感值）
真正难的不是写对那几行 Prepare，而是所有入口点——包括 API、后台任务、甚至 cron 脚本里的 SQL——都得过同一套参数化规则。漏掉一个，前面全白做。
