写Go程序的人，十有八九都跟Gorm打过交道。这东西用起来确实顺手，链式调用一写，SQL都不用自己拼了。但越顺手的东西，越容易让人忽略背后的细节。今天想聊的，就是那个最容易被忽略、却又最容易捅娄子的操作——关闭数据库连接池。
很多人写完代码，测试一跑，没问题，就完事了。等到线上跑个三五天，数据库连接数飙到上限，DBA打电话过来质问的时候，才一拍大腿：忘了关连接了。这种事，我见过太多次了。其实Gorm的文档里写得明明白白，连接池是需要关闭的，但大家总觉得那是框架的事，跟自己没关系。这种侥幸心理，迟早要还的。
先说说为什么必须关。Gorm底层用的是database/sql，这个标准库维护着一个连接池。你每次执行SQL，它就从池子里拿一个连接，用完了再放回去。听起来挺智能的，对吧？但问题是，这个池子本身是有生命周期的。如果你的程序长期运行，却从不关闭连接池，那这些连接就会一直占着数据库的资源不放。更麻烦的是，如果连接池里的连接因为网络波动或者数据库重启而失效了，你不去关闭重建，那这些“僵尸连接”就会一直躺在池子里，新请求来了也拿不到可用的连接，程序就卡死了。
那Gorm到底怎么关？很多人以为调用db.Close()就完事了。实际上，如果你用的是gorm.DB，直接调Close()确实能关掉底层的连接池。但如果你用的是sql.DB，就得注意了，关闭之后就不能再用了，得重新初始化。另外，Go 1.18之后，database/sql里加了个Stmt的关闭逻辑，Gorm也做了适配。所以，关闭的时候，最好把预编译的语句也一并处理干净，不然这些语句对象也会泄漏。
有个细节特别容易被坑。Gorm的AutoMigrate，还有它内部的日志、钩子这些，都会在后台开一些协程。这些协程如果没被妥善关闭，就算你把连接池关了，它们还会继续跑，继续尝试拿连接。这就像你把水龙头关了，但水管里的水还在流，迟早要漏到地板上。所以，关闭的顺序很重要：先关掉你自己创建的*sql.DB，再关掉Gorm的实例，再把那些后台任务停下来。顺序反了，就会报一堆莫名其妙的错误。
再聊一个实战里经常踩的坑。有些同学喜欢在函数里临时开一个数据库连接，用完就关。这在单测里没问题，但在高并发的生产环境里，频繁开连接、关连接，性能损耗相当可观。正确做法是，数据库连接池应该是全局的，程序启动时初始化一次，程序退出时才关闭。所以，关闭操作应该放在main函数的最末尾，或者用defer来执行。但这里又有个隐患：如果程序里用了信号量或者优雅退出机制，defer的执行顺序可能会被打乱，连接池就关不掉了。这时候，就得用context来传递退出信号，确保关闭逻辑一定能执行到。
说到优雅退出，就不得不提一下Go的http.Server。如果你用Gorm做Web服务，通常会在main里启动一个HTTP服务器，然后监听系统信号，收到SIGTERM或者SIGINT就触发关闭。这时候，你得注意关闭的顺序：先让HTTP服务器停止接收新请求，等正在处理的请求都完成了，再关闭数据库连接池。如果反过来，先关了连接池，那还在处理中的请求就会突然拿不到数据库连接，直接报错，用户看到的就是500错误。这种问题，线上排查起来特别费劲，因为报错信息五花八门，一会儿是“connection refused”，一会儿是“sql: database is closed”。
还有个偏门但很重要的点：Gorm的调试模式。如果你开了Debug()，它会把每一条SQL都打印出来。这个功能在开发阶段很好用，但如果你忘了关，并且又在生产环境跑了很久，那连接池里会积累大量未关闭的调试语句对象。这些对象虽然很小，但架不住量多，时间长了内存就吃紧了。所以，关闭连接池的时候，最好也把Gorm的日志级别恢复到默认，或者干脆在关闭前把调试模式关掉。
说了这么多，其实核心就一句话：关闭连接池不是可做可不做的收尾工作，而是程序健壮性的关键一环。你写代码的时候多花两分钟想想关闭逻辑，线上就能少熬两个通宵。Gorm本身已经帮你把大部分底层的活干好了，你只需要在正确的地方调用正确的关闭方法，剩下的交给框架就行。但前提是，你得知道“正确的地方”在哪儿，“正确的方法”是哪个。
再啰嗦一句。如果你用的是连接池中间件，比如PgBouncer或者ProxySQL，那Gorm这边的连接池关闭逻辑可能又不一样了。因为这些中间件自己会管理连接，Gorm的Close()可能只是断开与中间件的连接，而不是真正关闭物理连接。这种情况下，你得根据中间件的文档来调整关闭策略。别指望一个Close()走遍天下都不怕，具体问题具体分析才是正道。
连接池这个东西，看着不起眼，但它的生命周期管理，直接决定了你的程序能不能长时间稳定运行。下次写Gorm代码的时候，别忘了在加上那一行关闭的调用。别看它简单，关键时刻能救你一命。
