go goroutine性能关键在避免阻塞、控制并发规模、减少调度压力；goroutine泄漏是常见性能黑洞，需用pprof监控并用context控制生命周期；gomaxprocs默认即最优，盲目调大会增加开销；高并发短任务应使用worker pool而非无限goroutine。
Go 的 goroutine 调度本身是自动且高效的，**你几乎不需要手动“优化调度”，真正需要关注的是避免阻塞、控制并发规模、减少调度器压力**。盲目调大 GOMAXPROCS 或强行复用 goroutine 反而容易引发更严重的问题。
goroutine 泄漏：最常被忽略的性能黑洞
泄漏不是调度问题，但会让调度器持续管理已失效的 goroutine，最终拖垮整个程序。典型场景是：带缓冲 channel 未被消费、select 没有 default 或 timeout、HTTP handler 启动 goroutine 但没绑定 request 生命周期。
- 用
pprof/goroutine快照比对（curl http://localhost:6060/debug/pprof/goroutine?debug=2）看数量是否随请求线性增长 - 所有长生命周期 goroutine 必须有明确退出路径，推荐用
context.Context传递取消信号 - 避免在循环里无条件启动 goroutine：
for _, item := range items { go process(item) }→ 改为带sync.WaitGroup或 worker pool 控制并发数
GOMAXPROCS 不是越大越好
GOMAXPROCS 控制的是 P（Processor）的数量，即能并行执行用户代码的 OS 线程上限。默认值是 CPU 核心数，多数场景下就是最优解。
- 设为
1并不等于“单线程”——goroutine 仍可并发（通过协作式调度），只是无法并行执行 CPU 密集任务 - 设为远超物理核心数（如 100）会导致 OS 线程频繁切换，增加调度开销；GC 停顿时间也可能上升
- 仅当确认存在大量 I/O 等待 + 少量 CPU 计算，且监控显示 P 利用率长期低于 30%，才考虑小幅上调（比如 +2～+4）
什么时候该用 worker pool 而不是无限制 goroutine
每秒启动数千 goroutine 处理短任务（如解析 JSON、校验 token）看似轻量，但会触发调度器高频分配/回收 G 结构体，造成内存与 CPU 浪费。
立即学习“go语言免费学习笔记（深入）”；
- 适用 worker pool 的场景：
http.Handler、数据库批量写入、日志异步刷盘、文件批量处理 - 关键参数：worker 数量 ≈
GOMAXPROCS * 1.5（I/O 密集）或GOMAXPROCS（CPU 密集），用chan job+sync.WaitGroup实现 - 避免用
time.Sleep在 worker 内做轮询；改用time.AfterFunc或 channel 定时通知
真正影响 goroutine 性能的，往往不是调度器本身，而是你的 channel 使用方式、锁竞争粒度、GC 频率和内存逃逸。别盯着 runtime.Gosched() 这种函数——它几乎从不在生产代码里出现。
