sql.DB 是连接池管理器而非单个连接，应全局复用且避免频繁 Close；参数须用 ? 占位防注入；Scan 字段顺序与类型须严格匹配；Rows.Close() 必须显式调用并及时释放。
sql.DB 不是连接，而是连接池管理器
很多人一看到 sql.DB 就以为它代表一个数据库连接，结果在高并发下频繁调用 db.Close() 或误以为需要手动“复用”这个实例——这是最常踩的坑。实际上，sql.DB 是 Go 标准库对连接池、准备语句缓存、驱动适配的统一抽象，它本身线程安全，应作为全局单例长期持有。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 应用启动时调用
sql.Open()一次，拿到*sql.DB后直接设为包级变量或注入到依赖中，不要每次请求都新建 - 除非明确要关闭整个连接池（如服务退出），否则不要调用
db.Close()；它不会立刻断开所有连接，但会拒绝新请求并等待现有操作完成 - 连接空闲超时、最大打开连接数等行为由
db.SetMaxIdleConns()、db.SetMaxOpenConns()、db.SetConnMaxLifetime()控制，不设可能吃光数据库连接数
Query 和 Exec 的参数绑定必须用 ? 占位符，不能拼 SQL 字符串
写 db.Query("SELECT * FROM users WHERE id = " + strconv.Itoa(id)) 看似省事，实则埋下 SQL 注入和类型转换隐患。Go 的 database/sql 要求所有参数通过占位符传入，具体符号取决于驱动：mysql 驱动用 ?，postgres 驱动用 $1、$2，而 sqlite3 同时支持 ? 和 :name ——但你写的代码不该感知这些差异。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 一律使用
?占位符（mysql和sqlite3原生支持，pgx等现代 PostgreSQL 驱动也兼容） - 参数按顺序传入
Query()或Exec()，不要试图用 map 或命名参数（标准库不支持） - 如果真要用命名参数，得换
sqlx这类第三方库，但会引入额外抽象层，调试时堆栈更难追踪
Scan 时字段顺序和类型必须严格匹配 SELECT 列表
常见错误是 SELECT 了 5 个字段，却只给 Scan() 传 4 个地址，或者把 int64 当成 int 传进去，结果 panic 报 sql: Scan error on column index 2: converting driver.Value type []uint8 ("...") to a int。这不是驱动问题，是 Go 类型系统在帮你拦住隐式转换。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用
SELECT col1, col2, col3明确字段，别偷懒写SELECT *，尤其表结构后期有变更时 - Scan 目标变量类型必须与数据库列类型可映射：比如 MySQL
TINYINT(1)对应bool或int8，PostgreSQLTEXT对应string，JSONB对应[]byte或自定义 struct（需实现Scanner接口） - 不确定类型时，先用
interface{}接收再打印fmt.Printf("%T: %v", v, v)看实际值，比查文档更快
Rows.Close() 必须显式调用，且不能依赖 defer 在循环里
写 rows, err := db.Query(...) ; defer rows.Close() 看起来稳妥，但如果后续逻辑有 return 或 panic，defer 可能延迟执行，导致连接卡在池里不释放；更危险的是在 for rows.Next() 循环里写 defer rows.Close()，那第一次迭代就 close 了，后面全报 sql: Rows are closed。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
rows.Close()应该紧跟在for rows.Next()循环之后，且必须检查返回的 error（它可能包含真正的数据库错误） - 如果函数内有多处 exit 路径，用
if rows != nil { rows.Close() }加卫语句兜底，比嵌套 defer 更可控 - 用
db.QueryRow()时不用手动 Close，它内部已处理；但若用QueryRow().Scan()失败，仍要留意是否因底层 rows 未 clean 导致后续调用异常
最麻烦的其实是事务里的 Rows：一旦 tx.Query() 返回 *sql.Rows，你就得自己管好它的生命周期，标准库不会替你在 tx.Commit() 时自动关掉——这点容易被忽略，出问题时连接池耗尽却找不到源头。
