pprof是定位go性能问题的唯一可靠路径，必须正确挂载路由（如gin需r.get("/debug/pprof/*pprof", gin.wraph(http.defaultservemux))）、强制gc后对比heap快照、用?debug=2获取全量goroutine栈，并结合符号表和足够采样时长分析。
pprof 是唯一能绕过“我觉得是……”陷阱的路径。Go 微服务跑得慢，八成不是业务逻辑写得差，而是 mallocgc 占用高、goroutine 卡死在 semacquire、或 HTTP handler 里反复 json.Marshal —— 这些问题不靠真实 profile 数据根本没法定位。
pprof 接口返回 404 怎么办
常见错误现象：import _ "net/http/pprof" 启了 http.ListenAndServe(":6060", nil)，但访问 /debug/pprof/ 直接 404。
根本原因：nil mux 只注册了 /debug/pprof/ 路由前缀，而 Gin/Echo 等框架默认拦截全部请求，pprof 路由被吃掉了。
- Gin 用户必须显式挂载：
r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux)) - Echo 用户用：
e.Any("/debug/pprof/*", echo.WrapHandler(http.DefaultServeMux)) - 更稳妥的做法（尤其生产环境）：改用
runtime/pprof手动写文件，比如收到SIGUSR1时调用pprof.WriteHeapProfile(f)，避免暴露 HTTP 接口
heap profile 看不出内存泄漏？
常见错误现象：采了 /debug/pprof/heap，发现 json.Marshal 占比高，优化后 RSS 还是涨。
关键遗漏：默认 heap profile 只反映 inuse_space（当前存活对象），而泄漏往往藏在 allocs（累计分配量）或两次快照的净增长里。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 必须强制 GC 后再采样：
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" > heap1.pb.gz - 压测一段时间后再采一次：
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" > heap2.pb.gz - 对比净增长：
go tool pprof -base heap1.pb.gz heap2.pb.gz，重点关注 delta 值大的函数
top 显示 goroutine 很少，但 RSS 持续上涨
常见错误现象：ps aux 看 RSS 一路飙升，go tool pprof http://.../goroutine 的 top 却只列出几十个。
真相：/debug/pprof/goroutine 默认只返回状态为 running 或 runnable 的 goroutine；大量泄漏的 goroutine 实际卡在 chan receive、select 或 semacquire 上，被过滤掉了。
- 要查全量栈，加参数：
curl "http://localhost:6060/debug/pprof/goroutine?debug=2" - 配合
go tool pprof的top -cum查调用链，重点看是否大量 goroutine 堆在某个 channel recv 或 lock 上 - 典型诱因：未关闭的 channel、忘记
close()的 worker pool、或context.WithTimeout未被 cancel 导致 goroutine 永久阻塞
gRPC 客户端超时但服务端日志没异常
常见错误现象：客户端报 rpc error: code = DeadlineExceeded，服务端 pprof 和日志都正常，连接数也不高。
真正瓶颈常不在服务端代码，而在客户端配置或网络中间层。
- 检查客户端 dial timeout 和 call timeout 是否分离设置 ——
grpc.DialContext的 context 控制连接建立，ctx传入client.Method(ctx, req)才控制单次调用 - 确认是否启用了连接池：
grpc.WithTransportCredentials(insecure.NewCredentials())默认复用连接，但若每次 new client 就重连，会触发 TLS 握手开销 - 排查 sidecar 或 service mesh 层（如 Istio）的默认超时策略，它可能比 gRPC 客户端设得更短，且不透传错误码
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
