在Go中，db.Query(sql, args...)会自动触发预处理语句（prepared statement），而db.Prepare()则显式创建可复用的预处理句柄；二者在单次查询场景下功能等价，但复用性、连接生命周期管理和性能特征存在关键差异。
在go中，`db.query(sql, args...)`会自动触发预处理语句（prepared statement），而`db.prepare()`则显式创建可复用的预处理句柄；二者在单次查询场景下功能等价，但复用性、连接生命周期管理和性能特征存在关键差异。
在Go的database/sql包中，Query、Exec和QueryRow等方法默认支持参数化查询，底层已自动封装了预处理逻辑。例如：
// ✅ 自动预处理：安全、简洁、推荐用于单次执行
rows, err := db.Query("SELECT name FROM users WHERE id = ?", 123)
if err != nil {
log.Fatal(err)
}
defer rows.Close()
这段代码虽未显式调用Prepare，但database/sql驱动（如mysql或pq）会在内部完成：SQL解析 → 执行计划生成 → 参数绑定 → 执行 → 清理。整个过程对开发者透明，且天然防御SQL注入。
相比之下，显式使用Prepare适用于高频复用同一SQL模板的场景：
// ✅ 显式预处理：适合多次执行同结构查询（如批量插入/查询）
stmt, err := db.Prepare("INSERT INTO logs (level, msg) VALUES (?, ?)")
if err != nil {
log.Fatal(err)
}
defer stmt.Close() // 注意：必须关闭以释放资源
_, _ = stmt.Exec("error", "failed to connect")
_, _ = stmt.Exec("info", "user logged in")
_, _ = stmt.Exec("warn", "disk usage >90%")
然而需注意：Go的sql.DB基于连接池，Prepare并非全局复用。stmt绑定的是某次获取的物理连接；若该连接已被归还池中，后续stmt.Query()可能触发隐式重准备（re-prepare）——即驱动自动在新连接上再次执行PREPARE命令。这意味着在高并发下，Prepare + Query未必比直接Query更高效，甚至因额外握手开销反而略慢。
关键差异总结：
- 安全性无差别：两者均通过参数绑定防止SQL注入，绝不应拼接字符串构造SQL。
- 单次查询推荐db.Query()：代码更简洁，避免手动管理stmt.Close()，且性能与显式预处理基本一致。
- 高频复用才考虑Prepare：如循环执行数百次相同结构查询时，显式预处理可减少重复解析开销（实际收益取决于数据库协议与驱动实现）。
- 资源管理责任不同：db.Query()无需显式清理；stmt必须调用Close()，否则可能泄漏服务端预处理资源（尤其在MySQL中）。
实践建议：
- 默认优先使用db.Query(...)、db.Exec(...)等便捷方法；
- 仅当压测证实Prepare带来显著性能提升（如QPS提升5%+），且业务逻辑明确需要复用时，再引入显式预处理；
- 若涉及敏感操作（如动态表名/列名），预处理无法覆盖，需结合白名单校验等其他防护手段——预处理仅解决值参数的安全问题。
简言之：Go的“自动预处理”设计让开发者无需过早优化，先写清晰安全的代码，再用pprof和数据库慢日志验证瓶颈所在。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
