必须在http handler中避免直接查库，应使用context.withtimeout控制db调用、由业务层统一管理事务、优先批量查询，并借助go-zero model生成器和sync.pool优化性能。
避免在HTTP handler里直接查库
很多Go微服务一收到请求就立刻调用db.QueryRow或tx.Commit，看似简单，实则埋下性能隐患：数据库连接被阻塞、goroutine卡住、超时控制失效。尤其当DB响应慢或网络抖动时，整个HTTP worker线程会被拖住，QPS断崖式下跌。
正确做法是把DB操作和HTTP生命周期解耦，关键点有三个：
- 所有DB调用必须套
context.WithTimeout，超时值要小于HTTP总超时（比如HTTP设5s，DB操作设3s） - 别在handler里开事务——事务应由业务层统一管理，handler只负责传入
ctx - 批量操作优先用
db.QueryContext+rows.Scan，而非逐条db.QueryRowContext
用go-zero model生成器替代手写CRUD
手写DAO层代码不仅重复劳动多，还容易漏掉缓存、错误包装、连接复用等关键逻辑。go-zero的goctl model生成器能自动产出带缓存键管理、类型安全、错误隔离的CRUD代码，比手写快且稳。
例如生成MySQL用户模型：
goctl model mysql -src ./schema.sql -dir ./model -cache
生成的UserModel.FindOne会自动：
- 先查
cache:user:{id}，命中直接返回 - 未命中才走DB，并写回缓存（默认10分钟过期）
- 对
sql.ErrNoRows做标准化转换，不暴露底层错误
注意：生成后别直接改usermodelgen.go——它是自动生成文件，修改会被覆盖；业务逻辑写在usermodel.go里。
sync.Pool复用高频小对象
像JSON解析中的[]byte缓冲区、gRPC消息体、HTTP header map这类短生命周期对象，每次请求都make会触发GC压力。用sync.Pool能显著降低allocs/op。
但要注意三点：
-
Pool.New函数不能返回含指针字段的对象（比如&struct{}），否则可能残留脏数据 - 从
Get()拿到对象后，必须重置状态，比如buf = buf[:0]或mapClear(m) - 别在全局变量里初始化
sync.Pool——它本身无锁，但New函数可能被并发调用，确保线程安全
数据库连接池参数必须对齐下游承载力
很多人以为设置了db.SetMaxOpenConns(100)就万事大吉，结果压测时发现大量dial tcp: lookup xxx: no such host或context deadline exceeded。根本原因是连接池参数没和下游服务实际能力匹配。
关键参数组合：
-
SetMaxOpenConns：设为单个DB实例能稳定处理的并发数（通常20～50），不是越大越好 -
SetMaxIdleConns：建议等于SetMaxOpenConns，避免频繁建连 -
SetConnMaxLifetime：设为30分钟，防连接老化；SetConnMaxIdleTime设为5分钟，及时释放空闲连接
如果用的是go-zero，这些参数在etc/config.yaml里统一配置，不用散落在各处硬编码。
