每个 goroutine 初始栈大小为2kb，但实际内存占用约4.5–4.7kb；百万goroutine基础内存近4.5gb，gc需扫描所有活跃栈导致mark阶段变慢，应控制堆分配、避免泄漏并管理生命周期。
每个 Goroutine 真的只占 2KB 吗？
不是。2KB 是初始栈大小，但实际内存占用远不止这个数——实测中，每个空闲 goroutine 平均占 4.5–4.7 KB（64位系统），包含调度器元数据、栈结构头、G 结构体本身等开销。你启动 100 万个 goroutine，光基础内存就接近 4.5GB，还没算它们执行时栈动态增长、逃逸对象、GC 元信息。
为什么 goroutine 多了 GC 会变慢？
Go 的 GC 必须扫描所有活跃 goroutine 的栈来标记存活对象。哪怕这些 goroutine 全在 select {} 或 time.Sleep(10 * time.Second) 中挂起，只要没退出，它的栈就在扫描范围内。百万级 goroutine 下，GC mark 阶段耗时明显上升，pprof 中常看到 runtime.scanstack 占比突增。
- 避免让大量 goroutine 长期阻塞在无超时的 channel 操作或空
select上 - 用
context.WithTimeout包裹任务，确保 goroutine 有明确生命周期 - 监控
GODEBUG=gctrace=1输出，留意每次 GC 的scanned字节数是否随 goroutine 数量线性增长
怎么压低单个 goroutine 的真实内存成本？
关键不在“少开 goroutine”，而在“每个 goroutine 少分配堆内存”。栈上轻量对象不触发 GC；逃逸到堆上的小结构体、切片、bytes.Buffer 才是真凶。
- 小结构体优先值传递：
type ReqID [8]byte比*ReqID更省，也比string（底层含指针）更可控 - 预分配切片容量：
make([]byte, 0, 128)避免多次扩容拷贝，防止临时切片逃逸 - 高频短命对象走
sync.Pool：比如每个请求都 new 的json.Decoder、解析上下文 struct，缓存后可降低 30%+ 堆分配率 - 禁用隐式逃逸：别在
fmt.Println(&v)或传入接口变量前取地址，否则栈变量被迫上堆
goroutine 泄漏的典型信号和快速定位法
泄漏不是“开多了”，而是“该退的没退”。最常见表现是：进程 RSS 持续上涨、runtime.NumGoroutine() 单向增长、HTTP 接口延迟缓慢爬升。
立即学习“go语言免费学习笔记（深入）”；
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看所有 goroutine 当前调用栈，重点搜chan receive、select、time.Sleep后无对应 cancel 的地方 - 在 goroutine 启动处加日志：
log.Printf("started worker %p", &struct{}{})，配合defer log.Print("exited")，确认成对出现 - 用
go tool trace录制运行时行为，过滤 “Goroutines” 视图，看是否存在长期处于runnable或syscall状态却不执行的 goroutine
真实瓶颈从来不在“能不能开百万 goroutine”，而在于你有没有管住它们的内存出口和退出开关。栈大小只是起点，逃逸分析、对象复用、生命周期控制，缺一不可。
