GORM连接池即database/sql原生连接池，gorm.Open仅返回封装sql.DB的gorm.DB实例，真实连接由*sql.DB按需管理；必须调db.DB().Ping()验证连通性，并立即配置SetMaxOpenConns等参数。
没有区别。GORM 的连接池就是原生 database/sql 的连接池，它不新建、不封装、不代理——只是把 *sql.DB 包了一层。
为什么 GORM 没有独立的连接池
GORM 的 gorm.Open 返回的是 *gorm.DB，但它底层持有的仍是标准库的 *sql.DB 实例。所有连接获取、复用、超时、关闭逻辑，全部由 database/sql 自己完成。GORM 只负责把 SQL 语句拼出来、参数绑定好、再交给 *sql.DB 去执行。
-
gorm.DB().DB()就是拿到那个原生*sql.DB，之后调SetMaxOpenConns等方法，改的就是它 - 所谓“GORM 连接池配置”，本质就是对
*sql.DB的参数调优，不是在 GORM 层额外加了一套池 - 如果你用
sqlx.Connect或直接sql.Open，配的也是同一套参数，行为完全一致
性能对比：GORM vs sqlx vs 原生 sql
在纯查询吞吐场景下（如 SELECT * FROM person LIMIT 100），三者底层走的都是 *sql.DB.QueryContext，差异只在 ORM 层的开销：
- 原生
sql：零结构体映射、零反射、零链式构建，最快 -
sqlx：多了 struct tag 解析和 scan 映射，但无模型定义、无钩子、无事务上下文管理，比 GORM 轻量得多 -
GORM：额外承担模型校验、回调触发（BeforeCreate等）、关联预加载解析、SQL 构建链式状态维护——这些在高并发简单查询中会构成可观开销
实测数据（2W 行表，Mac 本地 MySQL）显示：GORM 查询耗时比原生 sql 高约 15%～25%，比 sqlx 高约 8%～12%，差距随字段数、嵌套深度、条件复杂度线性放大。
容易被忽略的“伪连接池”陷阱
很多人误以为 “用了 GORM 就自动有了连接池”，结果线上 MySQL 报 Too many connections。根本原因不是 GORM 池不行，而是没真正启用池：
- 没调
db.DB().SetMaxOpenConns(n)→ 默认MaxOpenConns = 0（无限打开新连接） - 在 HTTP handler 里反复调
gorm.Open→ 每次都新建*sql.DB，旧池泄漏 -
SetMaxIdleConns(10)却没设MaxOpenConns，或设得比它小 → Go 1.12+ 直接 panic，报错"max idle conns exceeds max open conns" - 只依赖
db.Ping()做健康检查 → 它不探测池中空闲连接是否已断，失效连接要到Query()时才暴露
真正影响性能的从来不是“GORM 有没有池”，而是你有没有让那个原生池按预期工作：参数设对、复用到位、失效连接能及时淘汰。否则再快的 ORM 也救不了连不上数据库的服务。
