Go的error类型与系统负载无关，需手动采集NumGoroutine和MemStats等指标并注入自定义LoadError，HTTP handler中应主动返回503状态码及Retry-After头。
Go 里用 errors.New 或 fmt.Errorf 返回错误，不等于系统负载高时自动反馈错误
Go 的错误类型（error）本身和 CPU、内存、goroutine 数量等系统负载完全无关。你调用 fmt.Errorf("timeout")，它不会因为当前 runtime.NumGoroutine() 是 5000 就多加个 “load=high” 字段——错误值只是值，不是监控探针。
想让错误携带负载信息，必须手动采集、判断、注入。常见错误现象是：服务在高负载下 panic 或超时，但日志里只看到 "context deadline exceeded"，完全看不出当时 go tool pprof 已显示 goroutine 堆积到 10w+。
- 别依赖错误构造函数自动感知负载；它连当前时间都不感知，更别说
runtime.ReadMemStats - 如果真要“根据负载反馈错误”，得在关键路径上主动检查指标，再决定返回哪个
error - 典型场景：HTTP handler 中，当
runtime.NumGoroutine() > 5000且请求耗时 > 200ms，返回自定义错误ErrOverloaded，而非继续排队
用 runtime.MemStats 和 runtime.NumGoroutine 判断瞬时负载是否异常
这两个是 Go 运行时暴露的最轻量、无锁、可高频读取的指标，适合嵌入错误决策逻辑。注意它们反映的是“当前快照”，不是平均值或历史趋势。
容易踩的坑是直接拿 NumGoroutine() 和固定阈值比——比如写 if runtime.NumGoroutine() > 1000 { return ErrOverloaded }。但你的服务启动后基础 goroutine 就有 200+（http.Server、log、gc 等），阈值得结合压测基线定，不是拍脑袋。
立即学习“go语言免费学习笔记（深入）”；
- 先用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=1看稳态下的 goroutine 分布 -
runtime.ReadMemStats(&ms)要传地址，漏了&会导致 stats 始终为零 - 别在每请求都调用
ReadMemStats（它有微小锁开销），可降频采样，比如每 100 请求查一次 - 示例判断逻辑：
if runtime.NumGoroutine() > baseGoroutines*3 || ms.Alloc > uint64(500*1024*1024) { return fmt.Errorf("system overloaded: goroutines=%d, heap_alloc=%.1fMB", runtime.NumGoroutine(), float64(ms.Alloc)/1024/1024) }
把负载状态塞进 error，别用字符串拼接，用自定义 error 类型 + Unwrap
直接返回 fmt.Errorf("overloaded: %v", stats) 看似简单，但下游没法可靠识别这是负载错误——strings.Contains(err.Error(), "overloaded") 极其脆弱，日志格式一变就失效。
正确做法是定义带字段的 error 类型，并实现 Unwrap 和 Error 方法，让调用方能用 errors.As 安全断言。
- 字段建议至少包含：
Goroutines int、HeapAlloc uint64、Timestamp time.Time - 不要把整个
runtime.MemStats塞进去（结构体太大，且含 sync.Mutex） - 避免在 error 中存指针或闭包，会阻碍 GC 或引发意外引用
- 示例：
type LoadError struct { Goroutines int HeapAlloc uint64 Timestamp time.Time } func (e *LoadError) Error() string { return fmt.Sprintf("system overloaded: goroutines=%d, heap=%.1fMB", e.Goroutines, float64(e.HeapAlloc)/1024/1024) } func (e *LoadError) Unwrap() error { return nil }
HTTP handler 中返回 503 而不是 500，需配合 http.Error 和自定义 header
Go 的 http.ServeHTTP 不会自动把 error 转成 HTTP 状态码。你 return errors.New("overloaded")，handler 里没处理，最终可能返回 200 或 panic，而不是预期的 503 Service Unavailable。
真实生产环境里，503 必须带 Retry-After header，否则上游 LB 可能立刻重试，雪上加霜。但 Go 标准库不提供开箱即用的负载感知响应工具。
- 别用
log.Fatal或panic处理过载——这会让整个进程退出，比 503 更糟 - 在 handler 开头检查负载，命中阈值就直接
http.Error(w, "Service Unavailable", http.StatusServiceUnavailable) - 手动加 header：
w.Header().Set("Retry-After", "5") w.Header().Set("X-Load-Goroutines", strconv.Itoa(runtime.NumGoroutine())) - 注意：如果用了中间件（如 chi、gin），确保你的负载检查在中间件链中位置靠前，别等 JWT 验证完才看内存爆了没
errors.As 失败。 
