上下文切换损耗靠控制调度节奏和减少触发条件来压低：关键在worker池、缓冲channel、非阻塞io和gomaxprocs对齐容器限制；goroutine过多会因p数超cpu配额导致缓存失效、寄存器频繁保存恢复及队列争抢，使runtime.schedule占比异常升高。
直接结论：上下文切换损耗不是靠“避免”解决的，而是靠“控制调度节奏”和“减少触发条件”来压低——关键在 worker 池、缓冲 channel、非阻塞 IO 和 GOMAXPROCS 对齐容器限制。
为什么 goroutine 多了反而变慢？
Go 的 goroutine 虽轻量（初始栈仅 2KB），但当并发数远超可用 CPU 核心或 P 数量时，调度器会频繁在 M 线程上切换 G，导致：
– 缓存失效（L1/L2 cache miss 暴涨）
– 寄存器状态反复保存/恢复，吃掉可观 CPU 周期
– 全局队列争抢加剧，P 本地队列失衡，增加锁开销
典型现象是 pprof 显示 runtime.schedule 或 runtime.findrunnable 占比异常高，而用户代码执行时间占比下降。
用 worker 池硬限并发数，别让 goroutine 自由泛滥
不推荐为每个请求起一个 goroutine，尤其在 HTTP handler 或消息消费侧。应显式控制活跃 worker 数量：
– 使用带缓冲的 chan Task 作为任务队列
– 启动固定数量（如 runtime.NumCPU() 或根据压测确定）的长期运行 worker
– 主逻辑只负责投递任务，不创建新 goroutine
– 避免 sync.WaitGroup + go func() { ... }() 这类“每任务一协程”模式，它在 QPS 上万时极易触发调度风暴
示例中 workerCount = 4 比 len(requests) 更安全，哪怕有 10 万请求也只跑 4 个常驻 goroutine 消费。
缓冲 channel + 批量处理，减少 channel 阻塞频次
无缓冲 chan 是同步点，每次收发都可能触发调度；而合理大小的缓冲区能吸收流量毛刺，降低切换密度：
– 缓冲大小建议设为平均单次批量处理量 × 2～3（如日志写入设 make(chan []byte, 128)）
– 在 worker 内部用 select + default 尝试非阻塞批量取数，而非逐条 <br>– 配合 <code>time.After 或 context.WithTimeout 防止单次处理卡死导致整个 worker 挂住
注意：缓冲区过大（如 >10k）会显著增加内存占用，且无法缓解下游慢导致的积压，只是把问题从调度层转移到内存层。
GOMAXPROCS 必须匹配容器 CPU 限制
这是最容易被忽略的硬伤。宿主机有 16 核，但容器只分配了 --cpus=2，而 Go 默认设 GOMAXPROCS=16，结果是 16 个 P 争抢 2 个 M，大量 goroutine 在就绪队列里排队等待，实测 QPS 可跌 40% 以上：
– 容器内务必设置 GOMAXPROCS 环境变量，或启动时调用 runtime.GOMAXPROCS(n)
– 推荐使用 uber-go/automaxprocs，它能自动读取 cgroup v1/v2 的 cpu.max 或 cpu.cfs_quota_us 并设为最优值
– 不要依赖 runtime.NumCPU()，它返回的是宿主机核数，对容器无效
这个配置错一次，所有上层优化效果都会打折扣。
真正难的不是写几个 go 关键字，而是让调度器“有节制地工作”——worker 数量、channel 缓冲、GOMAXPROCS 三者必须协同，缺一不可。单独调优其中一项，往往掩盖不了另外两个点的恶化。
