sql注入必然发生而非可能，因用户输入未过滤即拼接会导致恶意代码执行；go通过占位符与预编译隔离数据与逻辑，但须正确使用参数化接口，禁用字符串拼接，表名列名等动态部分需白名单校验。
为什么 db.Query 直接拼字符串会出事
因为 SQL 注入不是“可能”发生，而是只要用户输入进来了，没拦住就一定发生。比如用 fmt.Sprintf 拼 WHERE name = '%s'，攻击者输 ' OR 1=1 -- ，整条查询就变成查所有数据。
Go 的 database/sql 默认不拼字符串——它靠占位符 + 预编译机制隔离数据和语句逻辑。但前提是：你得用对函数、传对参数。
- 必须用
db.Query/db.Exec/stmt.Query这类带参数的接口，别用db.QueryRow(fmt.Sprintf(...)) - MySQL 用
?，PostgreSQL 用$1，SQLite 也用?—— 不要手写数字或名字占位符再自己替换 - 哪怕只有一个参数，也要走参数传入，不要为了省事写成
"WHERE id = " + strconv.Itoa(id)
sql.Stmt 复用比每次 db.Query 更安全吗
复用 sql.Stmt 本身不提升防注入能力，但它强制你走预编译路径，且天然排斥字符串拼接。更重要的是：它把“准备语句”和“执行语句”拆开，让逻辑更清晰，不容易滑向手动拼接。
但要注意：Stmt 是连接池感知的，不是线程安全的全局对象；如果在高并发下用同一个 *sql.Stmt 被多个 goroutine 同时 .Query()，不会出错，但性能未必最优（内部有锁）。
- 适合固定 SQL + 频繁执行的场景，比如登录校验、订单查询
- 初始化时调用
db.Prepare("SELECT * FROM users WHERE email = ?")，返回*sql.Stmt - 后续都用
stmt.Query(email)，参数类型自动绑定，字符串/数字/bool 全部按值传递，不转义也不拼接 - 别忘了
defer stmt.Close()，否则 Stmt 对象长期占用连接资源
哪些情况看似用了预编译，其实还是漏了
最典型的是“半截预编译”：表名、列名、ORDER BY 字段、LIMIT 数值，这些无法用参数占位符，必须拼字符串。这时候如果来源不可信，照样中招。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
比如 SELECT * FROM ? 是语法错误，ORDER BY ? 在多数驱动里也不被允许（会报 sql: expected 0 arguments, got 1）。
- 表名/列名只能白名单校验：
map[string]bool{"users": true, "products": true}，不在里面就直接拒掉 - LIMIT 的数值可以用参数，但注意 PostgreSQL 要写成
LIMIT $1 OFFSET $2，MySQL 是LIMIT ?, ? - 动态 WHERE 条件别硬拼，改用
map[string]interface{}构建字段名白名单 + 参数列表分开处理 - 别信“我只拼数字就没事”——整数型注入一样存在，比如
id = 1 OR 1=1在未加引号时仍可能绕过
驱动差异导致的预编译行为不一致
MySQL 驱动默认开启客户端预编译（parseTime=true&loc=Local 不影响），但如果你用 github.com/go-sql-driver/mysql 并显式设 interpolateParams=true，它会在客户端模拟预编译——这看起来像防注入，实则只是把参数塞进字符串再发给服务端，**完全不防注入**。
PostgreSQL 驱动 lib/pq 和新驱动 pgx 默认走真正的服务端预编译，安全性更高；SQLite 基于本地文件，预编译是真·预编译，但要注意 sqlite3 驱动版本是否支持 Stmt 复用。
- MySQL 场景下务必确认连接串没开
interpolateParams=true - 检查日志或抓包看实际发送的语句：如果看到
SELECT * FROM users WHERE name = 'admin'...完整字符串，说明没走预编译 - 用
db.Stats()看OpenConnections和InUse可辅助判断 Stmt 是否被复用
事情说清了就结束
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
