pprof heap看不到分页导致的内存增长，因其只统计当前存活对象，而分页中的临时切片、rows.Scan结果、JSON中间值等在函数返回后即被GC回收，仅体现在allocs指标中；需结合allocs profile和goroutine分析定位真实问题。
pprof heap 采样为什么看不到分页导致的内存增长
因为 heap 只抓取当前**存活对象**，而分页逻辑中常见的临时切片、rows.Scan 结果、JSON 序列化中间值，往往在函数返回后就被 GC 回收——它们只出现在 allocs 指标里。如果你只跑 curl http://localhost:6060/debug/pprof/heap，很可能看到内存“很稳定”，但 top 的 RES 却持续上涨。
真正该看的是：curl http://localhost:6060/debug/pprof/allocs?debug=1，再用 go tool pprof -http=:8081 allocs.pprof 打开分析页面，点 top 看分配量最大的函数。
- 重点关注
GORM相关调用：比如(*DB).Find、(*DB).Limit、Rows.Scan - 如果看到大量
make([]uint8, ...)或make([]interface{}, N)，大概率是分页时未限制结果集大小，或Scan到了大字段（如TEXT、JSONB） - 注意
gorm.Model(...).Select("id,name").Limit(20).Offset(...)这类写法——它仍会把整行数据从 DB 拉到内存，再裁剪字段；真正省内存得靠数据库层投影，即显式写SELECT id,name FROM ...
GORM 分页 + Scan 导致 goroutine 阻塞的典型链路
不是所有泄漏都发生在堆上。分页接口若搭配 chan 或异步导出逻辑，很容易触发 goroutine 泄漏，而这类问题在 heap 里完全不可见。
典型错误模式：for rows.Next() { var u User; rows.Scan(&u); go processUser(u) } —— 如果 processUser 里有阻塞操作（如未设 timeout 的 HTTP 调用、无缓冲 channel 写入），这些 goroutine 就会堆积不退出。
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看全部 goroutine 堆栈，搜索runtime.gopark和select、chan send、net/http - 特别注意
goroutine数量是否随分页请求次数线性增长 - GORM 自带的
Rows对象本身不自动关闭，必须确保defer rows.Close()在循环外执行，否则底层连接和内存资源不会释放
分页场景下 sync.Pool 误用反而加剧内存压力
有人为优化分页性能，在 handler 里用 sync.Pool 缓存 []User 切片，但没控制最大长度或复用逻辑错位，结果池子里塞满不同容量的切片，GC 无法回收，最终比不用 Pool 还占内存。
sync.Pool 不适合缓存分页结果这类「生命周期短、尺寸波动大」的对象：
- 切片底层数组一旦被 Pool 缓存，即使切片本身被回收，数组仍驻留，直到 Pool 清理（通常只在 GC 时）
- 分页
Limit(10)和Limit(1000)复用同一个 Pool，小切片可能被大切片污染，造成内存浪费 - 更稳妥的做法是：对固定结构做对象池（如单个
User实例），或直接用栈上分配（var u User），避免切片池
为什么 GORM 的 Preload 关联查询会让 heap 快照失真
分页时用 Preload("Orders")，GORM 会先查主表 20 条，再发起 N+1 查询拉取关联数据。这些额外查询的中间结果（[]Order）不会绑定到分页结果生命周期，但会在堆上短暂存在，且容易逃逸到堆——尤其当 Order 结构体含指针字段或大字段时。
这种泄漏不是“一直不释放”，而是“高频分配 + GC 来不及清理”，表现为 allocs 指标飙升、heap 指标滞后、top RES 持续走高。
- 用
GODEBUG=gctrace=1启动服务，观察 GC 频率是否因分页请求陡增 - 改用 JOIN 查询替代
Preload：例如db.Joins("JOIN orders ON users.id = orders.user_id").Select("users.*, orders.id as order_id")，减少对象创建次数 - 如果必须用
Preload，加上Limit控制关联数据条数：Preload("Orders", db.Limit(5))
sync.Pool 里，或卡在某个没关的 rows 上，又或者被 Preload 的隐式查询反复拉进堆又丢弃。别只盯着 heap，allocs 和 goroutine 是更诚实的线索。 
