buffalo 中需手动调用 *sql.db.setconnmaxlifetime() 设置连接最大生命周期，因 pop 不暴露该配置；须在 pop.newconnection() 后获取底层 *sql.db 并显式设置（如 15 分钟），而非依赖 database.yml 或 pop.config。
Buffalo 的数据库连接池配置不在框架层，而在 sqlx 或 database/sql 底层
Buffalo 本身不管理数据库连接池参数，它依赖 sqlx（或直接 database/sql）初始化的 *sqlx.DB 实例。所谓“最大生命周期”，实际指连接在池中可存活的最长时间，对应的是 SetConnMaxLifetime() 方法——这个调用必须在 *sqlx.DB 创建后、被 Buffalo 使用前显式设置。
如何在 Buffalo 中正确设置 ConnMaxLifetime
Buffalo 的数据库初始化逻辑集中在 database.yml 解析和 pop.Connection 构建过程里，但 pop（Buffalo 默认 ORM）并不暴露 SetConnMaxLifetime() 的配置入口。你得绕过 pop 的封装，在 app.go 或 database.go 中手动干预底层 *sql.DB：
- 找到
pop.NewConnection()返回的*pop.Connection实例 - 调用其
DB字段获取底层*sqlx.DB - 再通过
.DB.DB取出原始*sql.DB（注意双层嵌套） - 立即调用
.SetConnMaxLifetime(10 * time.Minute)（推荐值：5–30 分钟）
示例代码片段（放在 app.go 初始化数据库之后）：
conn, err := pop.Connect("development")
if err != nil {
log.Fatal(err)
}
// 获取原始 *sql.DB
sqlDB := conn.DB.DB
sqlDB.SetConnMaxLifetime(15 * time.Minute)
为什么不能只改 database.yml 或用 pop.Config
database.yml 仅控制 DSN、方言、日志等启动参数，pop.Config 也不包含连接池生命周期字段。pop 的设计目标是简化 CRUD，不是精细控制连接池行为。如果你看到某些文档提到 max_lifetime 配置项，那基本是误传或混淆了其他 ORM（如 GORM）的语法。
- 设错位置（比如在
pop.LoadConfig()后才调SetConnMaxLifetime()）会导致部分已创建连接不受影响 - 值设得太短（如
30s）会频繁新建连接，增加 handshake 开销 - 值设得太长（如
24h）可能让连接卡在过期的 LB 后端或云数据库代理上，引发connection refused或i/o timeout
验证是否生效的简单方法
连接池参数无法通过 SQL 查询直接查看，但可通过日志和行为判断：
- 启动应用后，用
lsof -i :5432 | wc -l（PostgreSQL）观察连接数是否随负载稳定，而非持续增长 - 在连接空闲超时（如 15 分钟）后发一次请求，看是否触发新连接建立（配合 PostgreSQL 的
log_connections = on） - 写个临时 handler 打印
sqlDB.Stats()，检查MaxOpenConnections和Idle是否合理
真正起作用的永远是 *sql.DB 实例上的方法调用，而不是任何 YAML 配置或框架包装层——这点在 Buffalo 里尤其容易被忽略，因为它的抽象层级太高，反而把底层可控性藏深了。
