直接用gorm.open连接mysql，因其底层已封装sql.db连接池；需通过db.db()获取原生对象配置setmaxopenconns、setmaxidleconns和setconnmaxlifetime，并对dsn中用户名、密码、库名做url.queryescape编码。
直接用 gorm.Open 连 MySQL，别自己封装 sql.Open
很多人想手动调 sql.Open("mysql", dsn) 再套一层连接池逻辑，但 Iris 生态里主流做法是直接用 GORM —— 它底层已经接管了连接池管理，再自己包一层反而容易出错。官方示例、iris-admin 和社区高 star 项目（如 2025 年 5 月的 GORM 集成代码）全走这条路径。
关键点在于：GORM 的 *gorm.DB 对象本身不等于连接，它背后持有的 *sql.DB 才是真实连接池入口。所以配置必须落到 db.DB() 返回的原生对象上，而不是 gorm.Config 里。
-
dsn字符串末尾一定要加&parseTime=True&loc=Local，否则time.Time字段解析会出错或变成零值 - 不要在
gorm.Open前调sql.Open，GORM 会自己开连接；重复初始化会导致连接泄漏 - 如果用
os.Getenv读配置，记得对空字符串做strings.TrimSpace，否则密码带换行符会导致认证失败
SetMaxIdleConns、SetMaxOpenConns、SetConnMaxLifetime 怎么设才合理
这三个参数必须在拿到 *sql.DB 后立刻设置，且顺序无关紧要 —— 它们作用于底层连接池，和 GORM 调用无关。常见错误是只设了 SetMaxOpenConns 却忽略 SetConnMaxLifetime，导致 MySQL 的 wait_timeout 触发后连接卡死。
-
SetMaxIdleConns(10)：空闲连接上限，建议 ≤SetMaxOpenConns，太大会占资源，太小会导致频繁建连 -
SetMaxOpenConns(100)：最大并发连接数，参考你的 API QPS 和平均 DB 耗时；100 是中等负载安全值，压测后再调 -
SetConnMaxLifetime(1h)：强制回收连接，必须比 MySQL 的wait_timeout（默认 8 小时）短，推荐 1 小时
环境变量加载 DSN 时，密码含特殊字符怎么办
MySQL 密码里有 @、/、: 或 ? 时，sql.Open 或 GORM 的 DSN 解析会截断。这不是 Iris 的问题，是 URL 解析规则决定的 —— 必须对用户、密码、数据库名三部分单独做 URL 编码。
正确做法是用 url.QueryEscape 包裹敏感字段，而不是整个 DSN：
dsn := fmt.Sprintf("%s:%s@tcp(%s:%d)/%s?charset=utf8mb4&parseTime=True&loc=Local",
url.QueryEscape(m.dbUser),
url.QueryEscape(m.dbPassword), // ← 关键！
m.dbHost,
m.dbPort,
url.QueryEscape(m.dbTable))
漏掉任意一个 url.QueryEscape，都可能在上线后某天突然报 invalid connection 或 access denied，而且很难复现。
为什么 DB.Ping() 成功，但查表还是报 dial tcp: i/o timeout
这是最典型的“连接池假成功”现象：DB.Ping() 只验证初始连接通，不代表后续所有连接都能复用。真正的问题往往出在连接池耗尽或网络中间件（如 Kubernetes Service、云厂商 SLB）的 idle timeout 设置过短。
- 先检查
sqlDB.Stats()输出的OpenConnections是否长期接近SetMaxOpenConns上限 - 确认你的 SQL 查询是否没写
defer rows.Close()，导致连接未归还池中 - 如果跑在容器环境，把
SetConnMaxLifetime改成 30m，同时调整宿主机或 LB 的 idle timeout ≥ 45m
连接池不是“设了就稳”，它依赖你每次查询都显式释放资源，也依赖基础设施层的超时协同。漏掉任何一环，都会在流量高峰时崩得毫无征兆。
