每个 goroutine 实际内存占用约 4.5–4.7 kb（64位系统），含栈结构头、g 结构体及调度元数据；百万 goroutine 即耗近 4.5 gb 基础内存，且 gc mark 阶段须扫描所有活跃栈，导致 scanned 字节数线性增长、mark 耗时飙升。
每个 Goroutine 实际内存占用不是 2KB，而是约 4.5–4.7 KB（64位系统），含栈结构头、G 结构体、调度元数据等固定开销；启动百万 Goroutine 会直接吃掉近 4.5 GB 基础内存，且 GC mark 阶段必须扫描所有活跃栈——这才是压垮服务的真正起点。
怎么测出单个 Goroutine 的真实内存成本
别信“2KB”这个初始栈数字，它只是起点。真实开销得靠 runtime.ReadMemStats 对比前后差值来实测，尤其要排除 GC 干扰：
- 调用
runtime.GC()强制触发一次回收，再runtime.ReadMemStats记录基准值 - 批量启动 N 个空闲 Goroutine（比如只执行
select{}） - 再次
runtime.GC()+ReadMemStats，用HeapAlloc差值除以 N，就是均摊成本 - 注意：别用
NumGoroutine()做分母——它包含已退出但尚未被 GC 清理的 Goroutine，会低估单个开销
为什么 Goroutine 多了 GC 会变慢
Go 的三色标记 GC 必须遍历每个活跃 Goroutine 的整个栈来查找指针，哪怕它正卡在 time.Sleep(10 * time.Second) 或无超时的 chan receive 上。现象很典型：
-
pprof中runtime.scanstack占比飙升，mark 阶段耗时线性增长 -
GODEBUG=gctrace=1输出里，每次 GC 的scanned字节数随 Goroutine 数量同步上涨 - 即使 CPU 空闲、网络无压力，HTTP 接口延迟却缓慢爬升
控制 Goroutine 内存开销的三个硬手段
重点不在“少开”，而在“每个都轻”：
- 栈上优先：小结构体用值传递，比如
type ReqID [8]byte，别用*ReqID或string（后者底层含指针，易逃逸） - 切片预分配：
make([]byte, 0, 128)明确容量，避免扩容导致临时底层数组逃逸到堆 - 高频对象走
sync.Pool：如json.Decoder、解析用的bytes.Buffer，但记得每次Get()后手动Reset()，否则残留数据会污染后续使用
goroutine 泄漏的快速定位法
泄漏不是“开得多”，是“退不掉”。最有效的现场诊断方式就一种：
- 访问
/debug/pprof/goroutine?debug=2，搜索关键词：chan receive、select、time.Sleep后没有对应context.CancelFunc调用的位置 - 在 Goroutine 启动处加日志：
log.Printf("worker %p started", &struct{}{})，配合defer log.Printf("worker %p exited", &struct{}{})，看是否成对出现 - 用
go tool trace录制后，在 “Goroutines” 视图里找长期处于runnable却从不进入running状态的 Goroutine——大概率是 channel 缓冲区塞满或锁竞争卡死
真正难控的从来不是 Goroutine 数量上限，而是每个 Goroutine 在生命周期内悄悄分配的堆内存和栈深度——它们不会报错，只会让 RSS 持续上涨、GC 越来越慢、问题越来越难复现。
