单个 Goroutine 实际内存占用约 4.5–4.7 KB（64位系统），含 G 结构体（~300 字节）、栈头元数据、调度字段及 guard page；10 万 goroutine 基础开销近 450 MB。
每个 Goroutine 真实内存占用怎么算？别信“2KB”
“goroutine 初始栈 2kb”是事实，但生产环境里单个 goroutine 实际内存占用稳定在 4.5–4.7 kb（64位系统），这包括：g 结构体本身（约 300 字节）、栈头元数据、调度器关联字段、以及 runtime 预留的 guard page。你用 runtime.numgoroutine() 看到 10 万个 goroutine，光这部分基础开销就接近 450 mb，还没算它们执行时栈增长、堆逃逸对象、gc mark bitmap 占用。
验证方法很简单：
func measurePerGMem() {
var m1, m2 runtime.MemStats
runtime.ReadMemStats(&m1)
var wg sync.WaitGroup
for i := 0; i < 10000; i++ {
wg.Add(1)
go func() { defer wg.Done(); select {} }()
}
wg.Wait()
runtime.GC() // 强制回收残留
runtime.ReadMemStats(&m2)
fmt.Printf("10k goroutines ≈ %.2f KB each\n",
float64(m2.HeapAlloc-m1.HeapAlloc)/10000/1024)
}
注意：这个值会随 Go 版本微调，Go 1.22+ 因栈收缩更激进，空闲 goroutine 均值略降至 4.3 KB 左右，但业务逻辑一跑，立刻拉回 4.6 KB+。
网关场景下 Goroutine 泄漏的三大高发点
API 网关类服务最常因以下三类写法导致 goroutine 持续累积，runtime.NumGoroutine() 单向上涨，RSS 内存缓慢爬升：
- 无超时的
select {}或time.Sleep(math.MaxInt64)—— 尤其在中间件里做“长期保活”时 - channel 接收端未配
context.WithTimeout，上游断连后 receiver 仍在等<-ch - HTTP handler 中启动 goroutine 处理异步任务，但没把
req.Context()传进去，导致 cancel 信号无法穿透
快速定位命令：
curl "http://localhost:6060/debug/pprof/goroutine?debug=2" 2>/dev/null | \ grep -E "(chan receive|select|time\.Sleep)" | head -20
重点看这些调用栈是否对应已关闭的连接或超时请求——它们就是泄漏源。
控制网关 Goroutine 总量的硬手段：worker pool + bounded channel
网关不能靠“每个请求起一个 goroutine”硬扛，必须用有界 worker pool。关键不是池子多大，而是让 channel 缓冲区与业务节奏匹配：
- 缓冲区大小 ≠ 并发上限，而是「瞬时积压容忍量」。例如日志投递，每秒峰值 200 条、批处理 50 条 → 缓冲设
make(chan *LogEntry, 150)（≈ 3 批） - 无缓冲 channel（
make(chan struct{})）只用于信号通知，比如done或quit，避免漏通知 - worker 启动时必须绑定
context.WithTimeout(parentCtx, 30*time.Second)，防止单个任务卡死拖垮整池
示例核心结构：
type WorkerPool struct {
jobs chan *Request
done chan struct{}
wg sync.WaitGroup
}
func (p *WorkerPool) Start(ctx context.Context, n int) {
for i := 0; i < n; i++ {
p.wg.Add(1)
go p.worker(ctx, i)
}
}
func (p *WorkerPool) worker(ctx context.Context, id int) {
defer p.wg.Done()
for {
select {
case job := <-p.jobs:
// 处理 job，内部用 job.ctx 控制超时
case <-ctx.Done():
return
}
}
}
GC 扫描开销随 Goroutine 数量线性增长，这点最容易被忽略
Go 的 STW GC mark 阶段必须扫描所有**当前活跃 goroutine 的栈**，哪怕它正卡在 select {} 上什么都没干。百万 goroutine 下，runtime.scanstack 常占 mark 时间 60%+，pprof 里一眼可见。
缓解方式不是“少开 goroutine”，而是让不该活的 goroutine 尽快退出：
- 所有长周期 goroutine 必须带
context.Context，并在select中监听ctx.Done() - 避免在 goroutine 内部无条件
for {}，改用for ctx.Err() == nil - 用
GODEBUG=gctrace=1观察每次 GC 的scanned字节数，若该值随 goroutine 数量同步涨，说明栈扫描已成瓶颈
真正难控的从来不是“能开多少”，而是“怎么让开过的每一个都按时下班”。
