参数化查询防SQL注入的根本原因是分离SQL结构与用户输入，database/sql通过问号（MySQL/SQLite）或$1/$2（PostgreSQL）占位符配合参数传递实现，禁止拼接字符串。

用 database/sql 的参数化查询代替字符串拼接

SQL 注入的根本原因是把用户输入直接拼进 SQL 字符串里。Go 标准库 database/sql 原生支持参数化查询，只要不用 fmt.Sprintf 或 + 拼接 SQL，就能拦住绝大多数注入。

正确做法是用问号占位符（MySQL/SQLite）或 $1/$2（PostgreSQL），再把变量作为参数传给

// ✅ 安全：参数化查询（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，就会映射失败，看似没报错，实则字段为空——这可能让后续权限判断、日志记录等逻辑误判。

• 统一用 db tag 显式声明映射关系：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），就等于开门揖盗。