必须用runtime/pprof手动打点才能捕获GORM事务真实CPU热点，因事务常在service层或定时任务中执行，不走HTTP handler；全局采样会混入调度噪音，且On-CPU火焰图无法反映锁等待等Off-CPU问题，需结合perf采集调度事件分析。
怎么用pprof抓到GORM事务里的真实CPU热点
直接开net/http/pprof是没用的——事务逻辑往往不走HTTP handler，而是藏在service层或定时任务里。必须用runtime/pprof手动打点，否则火焰图里根本看不到db.Transaction或db.Commit的调用栈。
实操建议：
- 在事务入口处加
pprof.StartCPUProfile(f)，出口处pprof.StopCPUProfile()，避免被其他协程干扰 - 别用
http://localhost:6060/debug/pprof/profile?seconds=30这种全局采样，它会混入大量无关goroutine的调度噪音 - 如果事务里有JSON序列化、时间格式转换等操作，火焰图上
json.Marshal或time.Time.Format可能比db.Commit还宽——说明瓶颈根本不在数据库，而在Go层数据加工
GORM事务慢，先看是不是锁住了再看是不是SQL慢
On-CPU火焰图只显示CPU在忙什么，但GORM事务卡住90%的情况是Off-CPU：比如db.Transaction卡在等待行锁，或db.Save卡在等待连接池释放。这时候On-CPU图里全是空白或只有runtime.futex，得立刻切到Off-CPU火焰图。
关键动作：
- 用
perf record -e sched:sched_switch -g --call-graph dwarf -p $(pgrep yourapp)采集调度事件（Linux环境） - 生成Off-CPU火焰图后，重点看栈顶是不是
database/sql.(*Tx).Commit或gorm.io/gorm.(*DB).Transaction，下面压着runtime.futex或internal/poll.runtime_pollWait - 如果看到
sync.(*Mutex).Lock反复出现，说明不是数据库锁，而是你代码里对共享map或cache做了无保护写入
事务里Preload和Save混用，火焰图会暴露双重开销
常见错误写法：db.Transaction(func(tx *gorm.DB) error { tx.Preload("Orders").First(&user); user.Name = "new"; tx.Save(&user); return nil })。这段代码在火焰图里会出现两个明显宽条：一个在preload路径下（N+1或全表JOIN），另一个在save路径下（结构体反射映射+SQL生成）。
为什么这样写更危险：
-
Preload在事务内执行，会延长事务持有锁的时间，加剧阻塞 -
Save时GORM默认把整个struct全字段UPDATE，哪怕只改了一个字段；火焰图里reflect.Value.SetMapIndex耗时飙升，说明反射开销已成瓶颈 - 解决办法不是关Debug，而是拆事务：Preload放事务外查，只在事务内做
tx.Model(&user).Select("name").Updates(...)
连接池耗尽时，火焰图里看不到SQL，只看到一堆goroutine挂起
当db.Config.ConnMaxLifetime设得太长，或事务没正确defer tx.Rollback()，连接池会慢慢被占满。此时压测接口P99飙升，但火焰图里既没有数据库函数，也没有业务逻辑热点，只有一堆runtime.gopark堆在database/sql.(*DB).conn附近。
这是最典型的“假CPU空闲真系统卡死”场景。验证方式：
- curl
http://localhost:6060/debug/pprof/goroutine?debug=2，搜conn和acquireConn，看是否有上百个goroutine卡在select { case - 检查
db.Stats().IdleConnections是否长期为0，db.Stats().OpenConnections是否接近MaxOpenConns - 临时把
MaxOpenConns调高一倍，如果P99骤降，基本坐实是连接池瓶颈，而不是SQL或代码问题
db.Transaction直通runtime.futex的调用链，就是最关键的分水岭。 
