USE指标指利用率（Utilization）、饱和度（Saturation）、错误率（Errors），是Brendan Gregg提出的系统监控黄金法则；Go程序需它因pprof/expvar不直接暴露goroutine饱和度、HTTP错误率等关键维度，须整合进USE框架才能有效定位资源瓶颈。
什么是 USE 指标，为什么 Go 程序需要它
USE（Utilization, Saturation, Errors）是 Brendan Gregg 提出的系统级监控黄金法则，不是 Go 专属，但对排查 Go 服务资源瓶颈极其有效。Go 程序常因 CPU 利用率高、goroutine 饱和、net/http 错误激增等问题表现异常，而 pprof 或 expvar 默认不暴露饱和度（如运行中 goroutine 数 vs 可调度 P 数）、错误率（如 HTTP 5xx 占比）等关键维度。直接看 runtime.NumGoroutine() 或 http.Server.ErrorLog 不够，得把它们组织进 USE 框架里才可横向比对。
如何采集 Go 进程的 Utilization 和 Saturation 数据
Go 的 Utilization 指标（如 CPU、内存占用）可从 runtime.ReadMemStats() 和 runtime.GOMAXPROCS(0) 推导；Saturation 更关键也更易被忽略：比如 goroutine 饱和度 = runtime.NumGoroutine() / runtime.GOMAXPROCS(0) * 100（粗略估算，实际需结合 runtime.NumCgoCall() 和阻塞型系统调用情况）；而 channel 饱和度可通过反射或自定义 wrapper 监控缓冲区填充率，但生产环境建议只监控关键 channel（如任务队列），避免反射开销。常见错误是把 NumGoroutine() 当作绝对阈值告警——它本身无意义，必须结合 P 数和 GC 周期观察趋势。
- 避免每秒调用
runtime.ReadMemStats()多次，它会触发 STW 小停顿；改用memstats.Alloc+memstats.Sys差值估算活跃内存 -
runtime.LockOSThread()后创建的 goroutine 不计入全局调度器统计，这类 goroutine 饱和需单独计数 - 若用
golang.org/x/exp/trace，trace.Start()会显著增加调度器开销，仅调试开启
如何结构化暴露 Errors 指标并关联 HTTP 请求
Go 标准库不自动聚合错误，http.Server 的 ErrorLog 是文本流，无法直接用于 Prometheus 抓取。正确做法是：在 http.Handler 外层包装中间件，用 prometheus.CounterVec（或轻量级 expvar.Map）按状态码、路径、延迟区间打点。重点不是记录所有错误，而是区分“预期错误”（如 404）和“异常错误”（如 500 内部 panic、503 超时）。容易踩的坑是中间件里 recover() 捕获 panic 后未重置 response writer header，导致 Content-Length 错误或连接复用失效。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用
http.MaxHeaderBytes和ReadTimeout防止慢速攻击伪造高错误率 - 对
context.DeadlineExceeded错误，应归入503而非500，否则混淆故障类型 - 若用
chi或gin，优先用其内置 error handler 注册机制，而非 rawhttp.ServeMux
如何用 Prometheus + Grafana 呈现 USE 三维度联动
单个指标没意义，USE 的价值在交叉分析。例如当 go_goroutines 持续 > go_goroutines{job="api"} / go_goroutines{job="api"} offset 5m 上升，且 rate(http_request_duration_seconds_count{code=~"5.."}[5m]) 同步跳升，基本可断定是 goroutine 泄漏引发下游超时。Prometheus 查询要避免高频抓取 expvar（默认每 15s 一次），建议用 promhttp.Handler() 暴露指标，并通过 scrape_interval 控制频率。Grafana 面板里，把 Utilization（CPU、内存）、Saturation（goroutines、channel full rate）、Errors（5xx rate）放在同一时间轴对比，比单独看 dashboard 有效得多。
立即学习“go语言免费学习笔记（深入）”；
真正难的是定义“饱和”的业务语义——比如一个支付服务，goroutine 数过千未必异常，但若其中 80% 都卡在 database/sql 的 Rows.Next()，那才是真饱和。这需要你主动埋点，而不是依赖通用指标。
