GORM本身不提供“连接超时”配置入口，真正起作用的是MySQL驱动DSN中的timeout参数，仅控制新建连接阶段（TCP握手+认证）耗时上限，与空闲连接、读写超时完全无关。
直接说结论：GORM 本身不提供“连接超时”配置入口，真正起作用的是底层 sql.DB 的 DialContext 行为，必须通过 MySQL 驱动的 DSN 参数或 mysql.Config 显式设置 timeout，且该值只影响**新建连接阶段**，和空闲连接、读写超时完全无关。
DSN 中的 timeout= 是唯一生效的连接超时控制
很多人误以为 SetConnMaxIdleTime 或 http.Transport 配置能管连接建立，其实不能。MySQL 驱动层唯一认的连接超时参数就是 DSN 里的 timeout：
-
timeout=5s：从开始拨号（net.Dial）到完成 TCP 握手 + TLS + MySQL 协议认证的总耗时上限 - 它不控制后续任何操作，连接一旦建好，这个参数就彻底失效
- 若网络抖动或 DB 端 SYN 队列满，这个超时能防止
gorm.Open卡死在阻塞状态 - 推荐设为 3–10 秒；设太短（如 500ms）易在高延迟网络下频繁失败；设太长（如 30s）会拖慢故障恢复
不要和 ReadTimeout/WriteTimeout 混用
readTimeout 和 writeTimeout 是独立参数，它们控制的是连接建立后执行 SQL 时的 I/O 超时，不是连接本身：
-
readTimeout=2s：执行SELECT后，等待第一条结果包到达的最长时间 -
writeTimeout=2s：向 MySQL 发送完整 query 字符串的最大耗时（含网络传输） - 这两个值如果设得太小，可能在大结果集或慢查询时误杀正常请求；设得太大则掩盖真实性能问题
- 它们和
timeout并行生效，互不影响——一个管“连不上”，两个管“连上了但卡住”
SetConnMaxIdleTime 不是连接超时，别配错地方
这是最容易被误解的一点：SetConnMaxIdleTime 控制的是连接池里**空闲连接存活多久**，不是“连接要花多久建立”：
立即学习“go语言免费学习笔记（深入）”；
- 它必须配合
SetMaxIdleConns使用，否则空闲连接压根不会进池子，此参数无效 - 它的单位是
time.Duration，例如45 * time.Second，且必须在调用db.DB()后设置 - 它和 DSN 中的
timeout完全无关；前者管“连完之后放着不动能放多久”，后者管“连这个动作本身最多忍几秒” - 如果你看到
invalid connection错误，大概率是SetConnMaxIdleTime设得比 MySQL 的wait_timeout还长，而不是timeout没设
真正容易被忽略的点是：所有这些超时参数都只对新连接生效；已建立的连接不会因为改了 DSN 就自动重连。上线前务必验证 DSN 解析是否正确，比如用 mysql.ParseDSN(dsn) 手动检查 timeout 是否被识别为非零值。
