pprof 用不对90%内存问题定位不到：需显式注册、独立端口、分场景采样（heap/goroutine/allocs），用 go tool pprof 交互分析，慎用 sync.pool，优先原生 net/http 处理 json。
Go 微服务中 pprof 用不对，90% 的内存问题根本定位不到
直接上手 pprof 却只看 /debug/pprof/heap?debug=1 文本输出？这基本等于没查。真实内存压力往往藏在运行时持续累积的 goroutine 堆栈、未释放的 sync.Pool 对象、或 http.Transport 默认复用连接池里。
- 必须启动时显式注册：
import _ "net/http/pprof"+ 启动独立http.ListenAndServe端口（别和主服务共用） - 采样要分场景：
heap看堆内存快照，goroutine看阻塞协程（尤其runtime.gopark占比高说明有锁或 channel 死等），allocs才能发现高频短命对象泄漏 - 别信浏览器直接打开的文本视图——用
go tool pprof http://localhost:6060/debug/pprof/heap进交互模式，输入top10或web生成调用图，重点盯runtime.mallocgc上游函数
sync.Pool 不是缓存，滥用反而增加 GC 压力
把 sync.Pool 当成通用对象池塞 Struct{} 或小切片？它不管理生命周期，只按 GC 周期被动清理。高频 Put/Get 但对象实际存活跨多个 GC 周期时，Pool 会不断扩容底层数组，反而拖慢分配速度。
- 适用场景极窄：临时缓冲区（如 JSON 解析用的
[]byte）、固定结构体（如 HTTP header map）、且单次使用后立即丢弃 - 务必实现
New函数：避免 Get 返回 nil 后 panic；但New里别做复杂初始化（比如开 goroutine 或读文件） - 注意 Pool 是 per-P 的，如果服务启用了
GOMAXPROCS调整，实际内存占用是 P 数 × 每个 Pool 的平均容量
选 rpc 框架前先问：你真需要框架级序列化和拦截器吗？
很多团队一上来就选 gRPC-Go 或 Kitex，结果发现 70% 接口只是透传 JSON，还硬套 Protobuf 编解码 + TLS 握手 + 流控熔断——这些全在吃内存。真实微服务间通信，80% 场景用原生 net/http + json.Encoder/Decoder 更轻量。
-
gRPC-Go默认启用gzip压缩，但小 payload（grpc.WithCompressor(nil) -
Kitex的remote.Client默认开启连接池和重试，若下游稳定，关掉WithRetryTimes(0)和WithConnectionPoolSize(1)可省下数 MB 内存 - 如果只是内部服务调用，用
http.DefaultClient配Transport.MaxIdleConnsPerHost = 32就够了，别引入整个框架
runtime.GC() 在生产环境手动触发 = 给自己埋雷
看到 RSS 上升就写个定时器跑 runtime.GC()？Go 的 GC 是并发标记清除，强制触发会打断正常调度，导致 STW 时间不可控，尤其在高 QPS 下可能引发雪崩。真正该做的是控制对象逃逸和减少堆分配。
立即学习“go语言免费学习笔记（深入）”；
- 用
go build -gcflags="-m -l"查逃逸分析，标红的变量尽量改栈分配（比如传指针不如传值，小 struct 别加*） - 字符串拼接别用
+（触发多次 alloc），用strings.Builder或预分配bytes.Buffer - HTTP handler 中避免闭包捕获大对象（比如把 *sql.DB 或 *redis.Client 闭包进 handler，会导致整个连接生命周期持有所属 struct）
内存优化最麻烦的从来不是某行代码，而是对象生命周期和 GC 触发时机之间的错位——这点连 pprof 都不会直接告诉你，得结合 runtime.ReadMemStats 里的 NextGC 和 LastGC 差值反复验证。