go语言mysql连接需主动重试，因sql.open仅初始化连接池不建连；db.ping()仅验证至少一个连接可用，无法保证后续操作成功；必须配合setconnmaxlifetime（小于wait_timeout）、错误分类重试及幂等控制。
Go 语言本身不自动重连 MySQL，sql.Open 返回的 *sql.DB 是连接池抽象，不是单个连接；断线后首次调用 db.Query 或 db.Ping 失败时，必须由你主动处理重试逻辑——否则请求直接 panic 或返回 error。
为什么 db.Ping() 失败后不能只 retry 一次就完事
MySQL 连接中断后，*sql.DB 内部的空闲连接可能已失效，但连接池不会自动清理。下一次 db.Query 可能复用一个“看似存活”实则已断的连接，触发 io: read/write timeout 或 invalid connection 错误。
- 仅靠
db.Ping()成功，只能说明「至少有一个连接可用」，不能保证后续所有操作都成功 - 连接池中残留的坏连接会在后续请求中暴露，错误类型常为：
driver: bad connection、invalid connection、use of closed network connection - 高频重试（如每秒 ping）会浪费资源，且无法解决连接池内脏连接问题
SetConnMaxLifetime 和 SetMaxIdleConns 怎么配才真正防断连
这两个参数是防止连接陈旧的核心，但配置不当反而加剧问题：
-
SetConnMaxLifetime(5 * time.Minute)：强制连接在创建后最多存活 5 分钟，到期后被关闭并重建。这是对抗 MySQL 侧wait_timeout（默认 8 小时）最有效的手段 —— 不要设成 0 或超过 MySQL 的wait_timeout -
SetMaxIdleConns(10)：控制空闲连接上限。值太小（如 1）会导致频繁建连；太大（如 100）可能堆积大量即将过期的连接，增加握手压力 - 务必搭配
SetMaxOpenConns(25)使用，避免连接数爆炸。生产环境建议MaxOpen = 2–3 × QPS峰值，而非无脑设高
DSN 中哪些参数影响重连行为，哪些纯属误导
go-sql-driver/mysql 的 DSN 支持多个超时参数，但只有部分对「断线后恢复」起作用：
- 有效参数：
timeout=5s（建立 TCP 连接超时）、readTimeout=3s、writeTimeout=3s—— 它们让单次操作更快失败，便于你捕获错误并启动重试，但不等于自动重连 - 无效参数：
failover=true、retry=true等 —— 驱动根本不识别这些 key，写了也白写 - 危险写法：
tcp(127.0.0.1:3306,127.0.0.1:3307)多主机语法只用于故障转移（failover），不是重连机制；它不会在主库断开后自动切到备库重试，而是按顺序尝试每个地址，失败即报错
真正的重连逻辑该放在哪一层
不要在每次 db.Query 前手动 ping，也不要封装一个全局 SafeQuery 函数包住所有 SQL —— 这样做掩盖了错误根源，且难以区分「临时网络抖动」和「数据库彻底宕机」。
- 推荐做法：在业务关键路径（如 HTTP handler 入口或定时任务启动时）执行一次
db.Ping()，失败则记录告警 + 触发初始化重试流程（带指数退避） - 对单次查询失败，先判断错误类型：
errors.Is(err, sql.ErrConnDone)或匹配"invalid connection"、"driver: bad connection"，再决定是否重试（通常最多 1 次） - 事务中禁止自动重连：重试会导致
INSERT重复执行，必须由业务层控制幂等性
最易被忽略的一点：MySQL 服务端的 wait_timeout 和客户端的 SetConnMaxLifetime 必须错开（比如前者设 28800，后者设 300），否则连接会在刚好到期时被双方同时关闭，出现难以复现的偶发中断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
