参数化查询防SQL注入的根本原因是分离SQL结构与用户输入，database/sql通过问号（MySQL/SQLite）或$1/$2（PostgreSQL）占位符配合参数传递实现，禁止拼接字符串。
用 database/sql 的参数化查询代替字符串拼接
SQL 注入的根本原因是把用户输入直接拼进 SQL 字符串里。Go 标准库 database/sql 原生支持参数化查询，只要不用 fmt.Sprintf 或 + 拼接 SQL，就能拦住绝大多数注入。
正确做法是用问号占位符（MySQL/SQLite）或 $1/$2（PostgreSQL），再把变量作为参数传给 Query、Exec 等方法：
// ✅ 安全：参数化查询（MySQL）
rows, err := db.Query("SELECT name FROM users WHERE id = ?", userID)
// ❌ 危险：字符串拼接
query := "SELECT name FROM users WHERE id = " + userID // 万一 userID 是 "1 OR 1=1" 就完蛋
rows, err := db.Query(query)
- MySQL 和 SQLite 用
?；PostgreSQL 用$1、$2，顺序必须严格对应参数列表 - 不能对表名、列名、ORDER BY 字段做参数化——这些属于 SQL 结构，不是值，得靠白名单校验或
sqlx.In配合预处理逻辑 - 即使参数是整数，也别自己转成字符串再拼，交给驱动处理类型转换更安全
警惕 Scan 和 QueryRow 的类型不匹配风险
参数化能防注入，但若 Scan 时目标变量类型和数据库字段不一致，可能触发静默截断、溢出或 panic，间接导致业务逻辑错乱——比如本该拒绝的非法输入被“凑合”读取了。
- 用
int64接BIGINT，别用int（32 位系统下可能丢数据） - 读
TEXT或长VARCHAR时，优先用string，别用固定长度数组或[]byte除非明确需要二进制处理 - 对可空字段（
NULL），必须用sql.NullString、sql.NullInt64等类型，否则 Scan 会报sql: Scan error on column index X: unsupported Scan
使用 sqlx 处理结构体映射时注意字段名绑定
sqlx 能自动把查询结果映射到 struct，但默认按字段名（非列别名）匹配，且区分大小写。如果数据库字段是 user_name，而 struct 字段是 UserName，又没加 tag，就会映射失败，看似没报错，实则字段为空——这可能让后续权限判断、日志记录等逻辑误判。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
dbtag 显式声明映射关系：UserName string `db:"user_name"` - 避免在 SQL 中用 AS 别名绕过 tag，因为
sqlx默认不识别别名（除非启用BindNamed并配sqlx.DB.Mapper） - 执行
Get/Select前确认 struct 字段已导出（首字母大写），否则反射无法写入
预编译语句（Prepare）不是银弹，要结合连接池理解
有人以为调用 db.Prepare 就能彻底防注入或提升性能，其实 Go 的 database/sql 默认已对单条语句做连接级预编译缓存，手动 Prepare 只在复用频繁、生命周期长的场景才有意义，反而可能因未关闭导致句柄泄漏。
- HTTP handler 内不要每次请求都
db.Prepare+stmt.Close()，开销大于收益；直接用db.Query即可 - 若真需复用 stmt（如后台定时任务高频写入），务必确保
defer stmt.Close()在合适作用域，且注意 stmt 绑定的是某个具体连接，连接池回收后 stmt 会失效 - 预编译本身不增加额外防护——它只是把参数化查询提前解析一次，防注入的关键仍是“不拼字符串”，不是“有没有 Prepare”
最常被忽略的一点：所有从 URL 查询参数、表单、Header、JSON body 里取的值，只要进 SQL，就必须走参数化。哪怕你用了 ORM 或 sqlx，只要底层拼了字符串（比如自定义条件构造器里用了 fmt.Sprintf），就等于开门揖盗。
