性能优化：连接池、复用与常见坑

性能优化最容易见效、也最容易出错的是数据层与资源复用层。GoFrame 的数据库与 Redis 都自带连接池，配置得当能显著降低建连开销；本章围绕连接池参数、复用习惯与常见性能坑展开。

数据库连接池配置

GoFrame ORM 的连接池参数可直接写在 database 配置里（对应 gdb.ConfigNode，官方默认值即合理基线，按需调整）：

database:
  logger:
    level: "all"
    stdout: true
  default:
    link: "mysql:root:12345678@tcp(127.0.0.1:3306)/test?loc=Local&parseTime=true"
    debug: false            # 生产务必关闭 debug（SQL 全量打印开销大）
    maxIdle: 10             # 空闲连接上限
    maxOpen: 100            # 最大打开连接数
    maxIdleTime: "60s"      # 空闲连接回收时间
    maxLifeTime: "30m"      # 连接最长存活，避免被数据库侧回收后还复用
    queryTimeout: "5s"      # 查询超时，防止慢 SQL 拖垮协程

经验法则（结合实际压测微调）：maxOpen 不要无限大——超过数据库并发上限只会排队等待；maxLifeTime 建议小于数据库/中间代理的连接回收周期；查询类接口务必设 queryTimeout。参数名与语义以官方 ORM 使用配置章节为准。

Redis 连接池

Redis 配置同样带池化参数（官方 redis.* 配置说明，均可用时长字符串）：

redis:
  default:
    address: 127.0.0.1:6379
    db: 0
    maxIdle: 10
    maxActive: 100
    idleTimeout: "60s"
    maxConnLifetime: "30m"
    dialTimeout: "5s"
    readTimeout: "3s"
    writeTimeout: "3s"

低频操作较多时适当调大 maxIdle 可减少反复建连；所有超时参数都建议显式配置，避免网络抖动时请求长时间挂起。

复用意识：对象与连接都要复用

• 请求对象、配置解析结果只做一次：把 g.DB()、g.Redis()、g.Cache() 当作长期复用的单例，不要每次请求新建客户端。
• 不要为单条 SQL 反复开关连接——连接池正是为了复用而存在，链式调用结束即归还连接。
• 常用小对象（如 JSON 序列化缓冲）避免在热点路径上反复分配，善用池化或复用变量。

常见性能坑

• 调试模式上线：debug: true 会打印 SQL 与堆栈，QPS 直接掉一截，务必关闭。
• N+1 查询：列表接口里循环查详情是头号杀手。先一次查出主表，再按关联键批量查询（WhereIn）或使用官方 ORM 的模型关联能力。
• 慢 SQL 无感知：开启 ORM 日志后定期看慢查询，把“稳定在几十毫秒以上”的查询拉出来优化索引。
• 忘记分页上限：见分页章节，超大 size 会让数据库全表扫。
• 缓存穿透/雪崩：热点数据用 gcache/Redis 做缓存并设置合理过期与空值保护（见实战章节的 GetOrSetFuncLock 用法）。
• goroutine 泄漏：手写 go func() 没退出条件、ctx 不传递导致内部超时失效，是线上内存上涨的常见原因；优先用 grpool 或受控协程。

// 反例：循环内逐条查，产生 N+1
for _, id := range ids {
    u, _ := dao.User.Ctx(ctx).Where("id", id).One() // 每次一次往返
}
// 正例：一次 In 查询
list, err := dao.User.Ctx(ctx).WhereIn("id", ids).All()

注意点

• 优化前先量化：官方提供 pprof 性能分析（s.EnablePProf()）与压测章节，先看火焰图再动手。
• 连接池参数是“权衡值”不是“越大越好”，配合监控（连接池状态、慢 SQL）持续调整。
• 一次只优化一个变量并压测验证，避免多因素混合导致误判。

小结

性能优化 = 连接池参数合理 + 组件单例复用 + 消灭 N+1 与慢 SQL。先关 debug、设超时、看慢查询，通常就能解决 80% 的问题；剩下 20% 再用 pprof 定位。配置参数细节以官方文档 goframe.org 为准。