pprof分析需显式注册、避免全量导入、足够采样时间；日志需透传context以保trace链路完整；gRPC服务端必须监听ctx.Done()实现超时响应。
用 pprof 抓住 CPU 和内存热点
微服务跑着跑着变慢，第一反应不是加机器，而是看它到底在忙什么。Go 自带的 pprof 是最轻量也最准的切入点，但很多人只开 /debug/pprof 就以为万事大吉。
实际要注意三点：一是必须显式注册到 HTTP mux（默认不自动暴露），二是生产环境别用 net/http/pprof 全量导入（有安全风险），三是采样时间不够长会漏掉偶发抖动。
- 启动时手动挂载（避免全量引入）：
import _ "net/http/pprof" // 然后在你的 router 里： mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) mux.Handle("/debug/pprof/cmdline", http.HandlerFunc(pprof.Cmdline)) mux.Handle("/debug/pprof/profile", http.HandlerFunc(pprof.Profile)) mux.Handle("/debug/pprof/symbol", http.HandlerFunc(pprof.Symbol)) mux.Handle("/debug/pprof/trace", http.HandlerFunc(pprof.Trace)) - CPU 分析建议至少采集 30 秒：
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30 - 内存分析优先看
inuse_space（当前占用）和alloc_objects（累计分配），go tool pprof -http=:8081 http://localhost:8080/debug/pprof/heap
日志上下文丢失导致 trace 断链
用 OpenTelemetry 或 Jaeger 做分布式追踪时，经常发现某个 HTTP handler 有 span，但进来的 goroutine 日志里没 trace_id，或者下游调用直接变成新 trace。根本原因不是 SDK 没集成好，而是日志库没接上 context。
标准 log 包完全无视 context；zap 和 zerolog 虽支持字段注入，但不会自动从 context 提取 span context。必须手动透传或用 wrapper。
立即学习“go语言免费学习笔记（深入）”；
- 用
otelzap替代原生zap：import "go.opentelemetry.io/contrib/zapfield" logger := otelzap.New(zap.Must(zap.NewDevelopment()))
- 在 HTTP middleware 中把 trace_id 注入 context，并确保每个 goroutine 启动时携带该 context（比如
go fn(ctx, ...)，而不是裸写go fn(...)） - 检查日志输出是否含
trace_id字段：如果只有span_id没有trace_id，说明 propagation 失败，大概率是跨 goroutine 时 context 丢了
gRPC 客户端超时与服务端流控不匹配
客户端设了 context.WithTimeout，但服务端迟迟不返回，连接却一直 hang 着，甚至触发 TCP keepalive 后才断开。这不是网络问题，而是 gRPC 的 deadline 机制和服务端处理逻辑没对齐。
gRPC 的 timeout 只控制 client-side 的等待，服务端收到请求后是否响应、何时响应、是否做流控，全由服务端自己决定。常见坑是服务端用了 time.Sleep 模拟延迟，或没做 ctx.Done() 监听。
- 服务端必须主动监听
ctx.Done()并提前退出：func (s *Server) DoSomething(ctx context.Context, req *pb.Request) (*pb.Response, error) { select { case <-time.After(5 * time.Second): return &pb.Response{}, nil case <-ctx.Done(): return nil, ctx.Err() // 返回 CANCELLED 或 DEADLINE_EXCEEDED } } - 客户端不要只依赖
WithTimeout，加上WithBlock()+FailFast(false)可缓解重试风暴，但更关键是服务端配合 - 用
grpcurl测试时注意加-plaintext -rpc-timeout 2s，否则默认无超时，看不出问题
热更新后 goroutine 泄漏查不到源头
用 fsnotify + exec.Command 实现配置热重载或二进制热替换后，发现 goroutine 数持续上涨，runtime.NumGoroutine() 从几百涨到几千，但 pprof 的 goroutine profile 里全是 select 或 chan receive，找不到谁在起 goroutine。
本质是旧进程的 goroutine 没被正确清理，尤其是那些监听 channel、timer、signal 的长期运行协程。新进程起来了，老进程的 goroutine 还卡在阻塞原语里，又没被 GC 掉。
- 所有后台 goroutine 必须接受
ctx.Done()并退出：go func(ctx context.Context) { ticker := time.NewTicker(30 * time.Second) defer ticker.Stop() for { select { case <-ticker.C: doWork() case <-ctx.Done(): return } } }(parentCtx) - 热更新前，先 cancel 原 context，等几秒再 kill 旧进程（用
syscall.Kill(pid, syscall.SIGTERM)），别直接SIGKILL - 用
go tool pprof -goroutines对比新旧 profile，重点关注状态为chan receive且 stack trace 没有业务函数名的 goroutine —— 很可能就是没监听 cancel 的“幽灵协程”
真正难的不是知道这些技巧，而是每次上线前有没有把 pprof 端口、trace 上下文、gRPC 超时策略、goroutine 生命周期这四件事当成 checklist 过一遍。漏掉任意一个，调试成本就翻倍。
