-go test -memprofile=mem.out -memprofilerate=1 可捕获每次内存分配，配合 go tool pprof mem.out 查看存活对象；注意其不记录已gc对象，需结合 inuse_space 和 readmemstats 确认真实泄漏。
Go test 运行时内存暴涨，go test -memprofile 怎么用才有效
直接看内存是否真溢出，别靠 top 或任务管理器猜。Go 自带的内存分析工具必须配合 -memprofile 和 -memprofilerate 才能抓到真实泄漏点。
-
-memprofile=mem.out只在测试结束时写一次快照，如果测试中途就 OOM 了，它根本不会生成文件——得加-memprofilerate=1（设为 1 表示每次分配都记录，适合定位问题；上线前务必调高，比如1024*1024） - 必须用
go tool pprof mem.out查看，不能直接打开二进制文件；常用命令：top看最大分配者，web看调用图，list 函数名定位具体行 - 注意：
-memprofile不捕获 runtime GC 回收掉的对象，只记录“当前存活”的堆对象，所以看到某个结构体占大头，大概率是没被及时释放（比如闭包持有、全局 map 未删、channel 缓冲区积压）
测试中大量构造 []byte 或 string 导致 GC 压力过大
不是所有字节切片都要 new，尤其在 Benchmark 或循环测例里，重复分配是内存飙升主因。
- 用
sync.Pool复用常见大小的[]byte，比如固定 1KB/4KB 缓冲区；但注意：Pool 中对象可能被 GC 清理，不能依赖其长期存在 - 避免
string(b)频繁转换：每次都会复制底层数组；如只是读取，用unsafe.String(unsafe.SliceData(b), len(b))（Go 1.20+）绕过拷贝，但仅限可信数据且不修改底层 - 测试数据生成尽量延迟：用
func() []byte代替直接构造，让 defer 或子测试按需生成，而不是全量加载到内存
testing.T.Parallel() + 全局变量引发隐式内存累积
并行测试共享状态比想象中更容易埋雷，尤其是 map、slice、chan 这类可增长容器。
- 每个
testing.T实例应有独立数据空间；若共用一个map[string]int记录统计，多个并行测试会往里疯狂塞键，且无清理逻辑 - 不要在
init()或包级变量中预分配大结构体（如var cache = make(map[string]*HeavyStruct, 1e6)），测试启动即占内存，且无法随测试生命周期释放 - 用
t.Cleanup(func(){ ... })显式回收资源，比如关闭临时文件、清空测试用 map、重置 sync.Pool —— 它比 defer 更可靠，因为无论测试成功失败都会执行
使用 io.Pipe 或 bytes.Buffer 模拟 IO 时的缓冲区陷阱
测试中常用来替代真实网络或磁盘 IO，但默认行为容易吃光内存。
立即学习“go语言免费学习笔记（深入）”；
-
bytes.Buffer底层是动态扩容的 slice，写入 1GB 数据后，即使只读前 100 字节，整个底层数组仍驻留；用完立刻buf.Reset()，或改用buf.Truncate(0)避免扩容残留 -
io.Pipe()的 writer 侧如果没被 reader 消费，数据会堆积在内存管道中，直到写满 64KB（默认 buffer size）后阻塞；测试中若 reader 启动晚或 panic，writer 就卡住并持续占用内存 - 更稳的做法：用
io.LimitReader(r, n)控制最大读取量，或对io.Pipe加超时 context，避免死等
真正难防的不是单次大分配，而是小对象在高频测试中反复逃逸到堆、又没被及时回收——GC 暂停时间变长、堆峰值缓慢爬升，最后在 CI 上偶然触发 OOM。盯住 pprof 里的 “inuse_space” 而非 “alloc_space”，再结合 runtime.ReadMemStats 在关键节点打点，才能确认是不是真泄漏。
