生产环境Go服务需分层建立可观测链路：运行时指标（pprof）、结构化指标（Prometheus）、分布式追踪（OpenTelemetry）和日志（Zap + Loki）四者缺一不可；pprof须绑定0.0.0.0:6060、经反向代理鉴权、禁长期开启CPU profile；/metrics必须用promhttp.Handler()确保协议兼容与压缩；GODEBUG=gctrace=2输出走stderr，需确保未被重定向或吞没；自定义指标生产环境必须用client_golang而非expvar；pprof快照与Prometheus指标语义不同，不可混用告警。
生产环境 Go 服务的性能监控不是装一个库就完事，而是必须分层建立可观测链路：运行时指标（pprof）、结构化指标（Prometheus）、分布式追踪（OpenTelemetry）和日志（Zap + Loki）四者缺一不可。只开 pprof 或只暴露 /metrics 都会漏掉关键上下文。
如何正确启用 pprof 并避免线上误用
pprof 是调试利器，但默认配置在生产环境有严重风险：它不鉴权、不限流、暴露全量 goroutine 堆栈，一次 /debug/pprof/goroutine?debug=1 请求可能拖垮高并发服务。
- 监听地址必须绑定
0.0.0.0:6060（而非localhost:6060），否则 Kubernetes Pod 内无法被 sidecar 或运维工具访问 - 务必通过反向代理（如 Nginx 或 Istio Gateway）做基础认证和 IP 白名单，
net/http/pprof本身不支持任何鉴权逻辑 - 禁止长期开启
/debug/pprof/profile（CPU profile），它会强制 STW 采集，影响线上延迟；只在问题复现时临时启用，且采样时间不超过 30 秒 -
/debug/pprof/heap?debug=1可安全用于快速排查内存泄漏，但注意它返回的是当前堆快照，不是实时流；若看到inuse_space持续上涨，再结合go tool pprof下载二进制 profile 分析分配热点
为什么 /metrics 端点不能用 http.HandleFunc 自己实现
很多人图省事写 http.HandleFunc("/metrics", func(w http.ResponseWriter, r *http.Request) { ... })，结果 Prometheus 抓不到数据或 Grafana 显示超时——根本原因是缺失标准 HTTP 头和协议兼容性处理。
- 必须用
promhttp.Handler()，它自动设置Content-Type: text/plain; version=0.0.4; charset=utf-8和Cache-Control: no-cache，而手写 handler 容易漏掉 -
promhttp.Handler()支持gzip压缩响应体，对大指标集（如含大量 label 的 histogram）能减少 70%+ 传输体积；手写逻辑基本不处理压缩 - Prometheus 默认发
HEAD请求做健康探测，promhttp.Handler()正确返回200 OK，手写 handler 若没实现HEAD方法会直接 405 - 路径必须严格为
/metrics；若改用/debug/metrics，需同步修改 Prometheus 的scrape_configs中metrics_path字段，否则静默失败
GODEBUG=gctrace=2 在容器中为何常看不到输出
开了 GODEBUG=gctrace=2 却在 kubectl logs 或容器日志平台里找不到 GC 日志，不是配置错，而是输出流向和捕获方式不匹配。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
gctrace输出走stderr，但很多容器运行时（如 containerd）默认不把 stderr 重定向到 stdout；需在 Dockerfile 中加ENV GODEBUG=gctrace=2，并确保启动命令未重定向2>/dev/null - 若使用 log 库（如
log/slog或zap）接管了stderr，GC 日志会被吞掉；应单独 fork 一个 goroutine 捕获os.Stderr并转发到日志系统 - 输出无时间戳，单靠
gc #123无法定位具体时刻；建议启动时加stdlog.SetFlags(log.LstdFlags)，或用script -q -c "./myapp" /dev/null | ts补时间 -
gctrace=2比=1多打印各代对象统计（如tiny allocs:行），适合判断是否因 tiny allocator 泛滥导致 heap_sys 持续增长，但每行仍不含 GC 原因（如scavenge还是heap full），得结合runtime.ReadMemStats对比NextGC和HeapAlloc才能确认
自定义指标该用 expvar 还是 client_golang
expvar 简单轻量，但只适合单机调试；生产环境必须用 prometheus/client_golang，否则指标维度和生命周期管理会失控。
-
expvar不支持 label，无法按{path="/api/user", status="500"}切分请求错误率；所有计数器只能是扁平 key，告警和下钻分析几乎无法开展 -
expvar注册后不能删除，变量名冲突直接 panic；而promauto提供线程安全的懒注册，重复调用同名指标不会崩溃 -
expvar返回 JSON，虽可用curl调试，但 Prometheus 抓取需额外部署expvar_exporter中转；client_golang直接暴露文本格式，零依赖接入 - 真正该用
expvar的场景只剩两个：临时调试时快速暴露某个内部状态（如缓存大小），或 legacy 系统无法引入新依赖时妥协使用；新项目一律从prometheus.NewCounterVec开始
最常被忽略的一点：pprof 和 metrics 端点暴露的指标语义完全不同——pprof/goroutine 是瞬时快照，go_goroutines 是 Prometheus 指标，两者采集时机、精度、用途均不一致。混用它们做告警阈值（比如用 go_goroutines > 1000 触发重启）会导致误判，因为前者含 runtime 系统 goroutine，后者是采集周期内平均值。要盯住的是趋势，不是绝对数字。
