应按场景组合使用database/sql、sqlx与GORM：高频读写接口（如登录态校验）绕过GORM直用sqlx提升15%~30%性能；go-zero中需显式配置GORM连接池参数防泄漏，并禁用PrepareStmt；关联查询优先Joins+手动去重，避免Preload引发N+1或笛卡尔积。
直接用 database/sql 写增删改查，性能不差，但业务一复杂，SQL 拼接、事务控制、结构体映射就容易出错；GORM 能省力，但默认配置下容易拖慢响应、泄露连接、生成冗余 SQL；go-zero 自带的 sqlx 封装轻量，但缺关联查询和迁移能力。三者不是“选一个”，而是得按场景组合用。
什么时候该绕过 GORM，直接用 database/sql + sqlx
高频读写、字段固定、QPS 过万的接口，比如用户登录态校验、订单状态轮询、实时库存扣减——这些地方 GORM 的反射开销和中间层抽象反而成瓶颈。
-
sqlx的Get/Select比 GORM 的First/Find快 15%~30%，尤其在 struct 字段多、扫描列少时 - 手动控制
sql.Tx比 GORM 的Transaction更明确：不会因 panic 漏掉Rollback，也不会因 defer 顺序错乱导致提前 commit - 避免 GORM 的
SELECT *默认行为：用sqlx.Named显式指定字段，减少网络传输和 GC 压力
GORM 在 go-zero 里怎么避免连接泄漏
go-zero 的 mysql.New 初始化后返回的是单例 *gorm.DB，但 GORM 默认不自动回收空闲连接，K8s 环境下 Pod 重启频繁时容易堆积 stale connection。
- 必须显式配置
SetMaxIdleConns和SetMaxOpenConns，例如：db.DB().SetMaxIdleConns(10)、db.DB().SetMaxOpenConns(50) - 禁用 GORM 的
PrepareStmt（默认 true）：它会在首次查询时缓存预处理语句，但在短生命周期 Pod 中反而增加内存占用 - 不要在 handler 里调
db.Session(&gorm.Session{...})创建临时会话——每次都会新建 *sql.Conn，且不参与连接池管理
关联查询别全靠 GORM 的 Preload
Preload 看起来方便，但一对多时会触发 N+1 查询或产生笛卡尔积，比如查 100 个订单再 Preload("Items")，实际可能发出 101 条 SQL 或返回 100×平均商品数 行结果。
立即学习“go语言免费学习笔记（深入）”；
- 优先用
Joins+ 手动去重：一次 JOIN 查询，Go 层按主键合并子项，比多次 round-trip 更稳 - 对深度嵌套（如 Order → Items → Sku → Category），拆成两步：先查主表 ID 列表，再用
IN批量查子表，用 map 做内存关联 - go-zero 的
cache.NewNodeCache可配合使用：把高频关联数据（如商品类目）单独缓存，避免每次 JOIN
真正卡住性能的往往不是 ORM 本身，而是连接复用策略、预处理语句生命周期、以及 JOIN 时的数据膨胀量——这些细节在压测 QPS 突然掉到一半时才暴露，但日志里只显示 “timeout” 或 “too many connections”。
