上下文切换开销未消失，而是由调度器承担，但goroutine数量失控时runtime.schedule和findrunnable将占用30%+ CPU；活跃goroutine超NumCPU×100会导致跨P窃取频繁、cache失效、调度热点；pprof中schedule占比>25%且handler占比低，结合/debug/pprof/goroutine可见大量chan receive/semacquire/netpoll阻塞态；10万goroutine约耗200MB栈内存并加剧GC与调度压力；worker pool须配缓冲channel与固定数量。
直接结论：上下文切换开销不是“消失”了，而是被调度器扛住了——但前提是 goroutine 数量可控；一旦失控，runtime.schedule 和 findrunnable 就会吃掉 30%+ 的 CPU 时间，业务逻辑反而跑不动。
为什么 pprof 里 runtime.schedule 占比突然飙升
这不是调度器变慢了，而是你有太多 goroutine 在排队等执行。每个 goroutine 都要被调度器盯住：入队、出队、抢占、偷任务、检查是否阻塞……当活跃 goroutine 持续超过 runtime.NumCPU() * 100，P 的本地队列常为空，M 被迫频繁跨 P 窃取任务，cache line 大量失效，runtime.findrunnable 就成了热点。
- 典型现象：
pprof -http=:8080查 CPU profile，runtime.schedule或runtime.gosched_mcum 占比 >25%，而你的 handler 函数占比却很低 - 用
/debug/pprof/goroutine?debug=2看堆栈，如果大量状态是chan receive、semacquire或netpoll，说明它们卡在同步点上，不是在干活，是在等 - 别信“goroutine 很轻”，10 万个 goroutine ≈ 200MB 栈内存 + GC 扫描压力 + 调度元数据膨胀，OOM 和秒级延迟都是真实发生的
worker pool 必须带缓冲 channel 和固定数量
光写 for i := 0; i 不够，还得管好任务怎么进来、怎么分发。无缓冲 channel 是隐式同步点，一堵就积压；不设缓冲或缓冲太小，流量毛刺直接打穿 worker 吞吐。
- 任务 channel 建议带缓冲：
taskCh := make(chan Task, 1000)（大小按平均批处理量 × 2～3 设，比如日志聚合设 128，API 请求转发设 1000） - worker 数量别硬写死 50 或 200，优先用
runtime.NumCPU()作基线，再结合压测调：QPS 上去后看 P99 延迟拐点和runtime.NumGoroutine()曲线是否陡升 - worker 内部必须用
for t := range taskCh长生命周期消费，禁止在循环里反复go handle(t)—— 那等于把池子绕过去了 - 启动时别漏
close(taskCh)的配合逻辑，否则 worker 收不到退出信号，sync.WaitGroup等不到结束
GOMAXPROCS 必须对齐容器 CPU 限制
宿主机 64 核，容器只给了 --cpus=2，但 Go 默认 GOMAXPROCS=64，结果是 64 个 P 争抢 2 个 M，大量 goroutine 在就绪队列里空转排队——这不是并发高，是调度饿死。
立即学习“go语言免费学习笔记（深入）”；
- 容器启动时务必设环境变量：
GOMAXPROCS=2，或代码里runtime.GOMAXPROCS(2)（放在main()开头） - Kubernetes 场景下，建议用
resources.limits.cpu值自动注入 GOMAXPROCS，避免硬编码 - 验证方式：
curl http://localhost:6060/debug/pprof/schedule?seconds=30看采样里有多少 P 实际在 work stealing；若多数 P 的 runq 为空且 steal 为 0，说明 P 数远超可用 M
HTTP client timeout 和 resp.Body.Close 是隐式 goroutine 泄漏重灾区
一个没设超时的 http.Client.Do，可能让 goroutine 卡在 net/http.readLoop 里数分钟甚至更久；不关 resp.Body，连接不归还，后续请求只能新建连接——每条连接背后又是一个 goroutine。
- 所有
http.Client.Do必须传带超时的 context：ctx, cancel := context.WithTimeout(ctx, 3*time.Second)，用完立刻cancel() -
resp.Body.Close()必须 defer 或显式调用，哪怕你只读 status code；漏掉它，连接池会慢慢耗尽，新请求被迫创建新连接 + 新 goroutine - 别用全局默认
http.DefaultClient，自定义 client 并配Transport.MaxIdleConnsPerHost和IdleConnTimeout，减少连接复用失败导致的 goroutine 冗余
真正难的不是写出 worker pool，而是确认哪些路径会悄悄绕过它——比如中间件里直接 go logRequest()、异步回调没走任务队列、或者第三方库内部偷偷起 goroutine。这些点不挖出来，压测时 goroutine 数还是会指数级上涨。
