go的database/sql自带连接池，框架不接管；gorm/gin/echo中需手动调db.db().setmaxopenconns等参数，否则默认maxopenconns=0致mysql报too many connections，且setmaxidleconns若大于maxopenconns会直接panic。
Go 的 database/sql 自带连接池，框架本身不接管也不增强它；所谓“框架连接池配置”，本质就是对底层 *sql.DB 实例做合理参数调优。
为什么 GORM / Echo / Gin 里都得手动配 SetMaxOpenConns
框架（如 GORM、Echo 中的 DB middleware）只是封装了 *sql.DB 的使用方式，并不改变其池行为。GORM 的 gorm.Open 返回的是 *gorm.DB，但它底层仍共享一个 *sql.DB 实例——连接池参数必须通过 db.DB() 拿到原生句柄后设置。
- 常见错误：在 GORM 初始化时只传
&gorm.Config{}，却没调gormDB.DB().SetMaxOpenConns(20)→ 池仍用默认值MaxOpenConns=0（无限制），上线后 MySQL 很快报Too many connections - Gin/Echo 中若把
sql.Open写在 handler 里，每次请求都新建池 → 连接泄漏、fd 耗尽、database is closed频发 - 正确姿势：应用启动时全局初始化一次
*sql.DB（或*gorm.DB），注入到 handler 或 service 层复用
SetMaxIdleConns 设高了会 panic，不是警告
Go 1.12+ 对空闲连接数做了硬校验：SetMaxIdleConns(n) 若大于当前 MaxOpenConns 值，运行时直接 crash，错误信息为 "max idle conns exceeds max open conns"。
- 典型误配：
db.SetMaxOpenConns(5)后又db.SetMaxIdleConns(10)→ 立即 panic - 没设
SetMaxOpenConns时，默认是 0（无上限），此时SetMaxIdleConns(10)不会 panic，但空闲连接实际受驱动和系统限制，不可控 - 稳妥顺序：先
SetMaxOpenConns，再设 ≤ 它的SetMaxIdleConns；生产环境建议按MaxOpenConns × 0.5设，比如开 20 连接，空闲就留 10
连接失效不发生在 Ping()，而发生在 Query() 归还后
db.Ping() 只验证“此刻能建一个连并执行 SELECT 1”，它不检查池中已有空闲连接是否还活着。数据库侧（如 MySQL wait_timeout=300）或中间件（RDS Proxy、ProxySQL）主动断连后，连接仍躺在池里，直到下次被取出执行 Query() 才暴露 invalid connection 或 i/o timeout。
- 所以不能只靠
Ping()做健康检查；k8s readiness probe 若只调db.Ping()，可能误判服务可用 -
SetConnMaxLifetime是唯一能缓解该问题的机制：它强制连接“到期就丢”，不等 DB 来杀。推荐设为比数据库wait_timeout小 5～10 分钟，例如 MySQL 设了 300s，则 Go 侧设240 * time.Second - 注意：
SetConnMaxLifetime不是保活，它不发心跳，也不检测连通性，只是计时器一到就关掉连接
事务里用错方法会导致连接永远不归还
在事务中调用 db.Query() 或 db.Exec()，而不是 tx.Query() / tx.Exec()，会导致连接被事务独占却不释放——因为 db 方法走的是连接池主路径，而 tx 方法绑定的是事务专属连接，tx.Commit() 或 tx.Rollback() 才会真正归还。
- 现象：QPS 没涨，但
db.Stats().InUse持续上升，db.Stats().WaitCount开始累积 - 排查线索：
db.Stats().Idle接近 0，且MaxOpenConnections已打满 - 修复方式：所有事务内操作必须用
tx.前缀方法；QueryRow()系列虽自动 Close，但仍在事务上下文中，也必须用tx.QueryRow()
最易被忽略的一点：连接池参数调得再准，如果业务代码里漏掉 rows.Close() 或误用 defer db.Close()，池就等于没用。连接泄漏不是配置问题，而是资源管理契约没守住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
