本文详解 Go 应用中因 defer 误用和无限循环导致 PostgreSQL 连接持续累积、状态滞留为 idle 的典型问题，并提供安全复用连接、显式关闭及资源清理的完整实践方案。
本文详解 go 应用中因 `defer` 误用和无限循环导致 postgresql 连接持续累积、状态滞留为 idle 的典型问题，并提供安全复用连接、显式关闭及资源清理的完整实践方案。
在 Go 中使用 database/sql 操作 PostgreSQL 时，连接泄漏（connection leak） 是高频陷阱——尤其当逻辑嵌套在无限循环中且错误依赖 defer 时。你提供的代码中，for { ... } 无限循环导致 defer db.Close() 永远不会执行（因为函数永不返回），每次迭代都新建连接却从不释放，最终 pg_stat_activity 中大量连接长期处于 idle 状态，耗尽数据库连接池。
✅ 正确做法：连接复用 + 显式关闭 + 错误路径兜底
不推荐在循环内反复调用 GetNewConnection() 并依赖 defer —— 这既低效又危险。应改为：
- 单次初始化连接（复用连接池，非单连接）；
- 在每次业务逻辑后显式调用 db.Close()（若需彻底释放）或更优地 复用连接池，不主动关闭；
- 确保所有错误出口均能释放资源（如 defer 放在连接建立后立即声明）。
以下是重构后的健壮实现：
func runScheduler(dbname string) error {
// ✅ 1. 创建连接池（非单连接），复用并自动管理连接生命周期
db, err := database.GetNewConnection(dbname)
if err != nil {
return fmt.Errorf("failed to connect to database: %w", err)
}
// ✅ 2. defer 在函数退出时关闭整个连接池（推荐放在最外层）
defer db.Close()
for {
var count int
// ✅ 3. 使用 QueryRow，自动管理语句生命周期（无需 Prepare/Close）
err = db.QueryRow("SELECT COALESCE(COUNT(1), 0) FROM table").Scan(&count)
if err != nil {
log.Printf("query count failed: %v", err)
time.Sleep(10 * time.Minute)
continue // 跳过本次，避免 panic 或阻塞
}
if count == 0 {
// ✅ 4. 直接 Exec，无需 Prepare（简单 INSERT 场景）
_, err = db.Exec(
"INSERT INTO table(last_update_time, next_update_time, schedule_frequency) VALUES($1, $2, $3)",
time.Now().Unix(), 1464718530, 86400,
)
if err != nil {
log.Printf("insert failed: %v", err)
time.Sleep(10 * time.Minute)
continue
}
} else {
// ✅ 5. SELECT 不需要 Exec，应使用 QueryRow 或 Query
var nextTime int64
err = db.QueryRow("SELECT next_update_time FROM table").Scan(&nextTime)
if err != nil {
log.Printf("select next_update_time failed: %v", err)
time.Sleep(10 * time.Minute)
continue
}
// 处理 nextTime...
}
// ✅ 6. 每次循环结束休眠（注意：无需手动 db.Close() —— 连接池会自动回收空闲连接）
time.Sleep(10 * time.Minute)
}
}⚠️ 关键注意事项
- defer 在无限循环中无效：defer 仅在函数 return 时触发，而 for {} 永不退出，defer db.Close() 将永远等待，造成连接堆积；
- Prepare 并非必需：对一次性执行的 SQL（如定时任务中的 INSERT/SELECT），直接 db.Exec / db.QueryRow 更简洁、安全，database/sql 内部已做预处理优化；
- 连接池 vs 单连接：*sql.DB 本身是连接池抽象，GetNewConnection() 应返回配置合理的池（设置 SetMaxOpenConns, SetMaxIdleConns, SetConnMaxLifetime），而非每次新建物理连接；
- db.Close() 的时机：若需长期运行服务，不应在循环中频繁 Close/Reopen；应在程序退出前 defer db.Close() 释放全部资源；日常操作由连接池自动复用与回收；
- 监控验证：部署后可通过 SELECT * FROM pg_stat_activity WHERE state = 'idle'; 观察连接数是否稳定，配合 max_connections 参数合理调优。
✅ 总结
根本解法不是“每次关连接”，而是*理解 `sql.DB的池化本质，放弃手动管理单连接，拥抱连接池自动生命周期管理**。移除循环内的defer和重复建连，将db.Close()` 放在函数级 defer 中，并确保错误时跳过而非 panic，即可彻底解决 idle 连接堆积问题——既提升稳定性，又符合 Go 数据库最佳实践。
