提升Go协程调度效率的关键是减少阻塞、避免泄漏和竞争，而非手动干预；GOMAXPROCS应匹配CPU核数以平衡并行与开销，runtime.Gosched仅在极少数无阻塞长循环中慎用。
提升 Go 协程（goroutine）调度效率，关键不在“手动干预调度”，而在于让 Go 运行时更自然、更少阻塞地工作。GOMAXPROCS 和 runtime.Gosched 并非“加速开关”，而是用于修正常见误用的两个工具：前者控制并行上限，后者主动让出时间片。用错反而拖慢性能。
合理设置 GOMAXPROCS：匹配硬件，避免过度并发
GOMAXPROCS 控制的是可同时执行用户代码的操作系统线程数（即 P 的数量），默认值是 CPU 逻辑核数。它不决定 goroutine 总数，只影响能并行运行的 goroutine 上限。
- 不要盲目设高：比如在 4 核机器上设 GOMAXPROCS=100，不会让 100 个 goroutine 同时跑，只会增加调度器在 P 之间搬运 goroutine 的开销，还可能引发更多锁竞争和缓存失效
- 不要随意设低：设为 1 会强制所有 goroutine 在单个线程上协作式调度，哪怕有空闲 CPU 也无法利用，CPU 利用率压不上去
- 动态调整需谨慎：仅在明确场景下才临时修改，例如长时独占计算任务中短暂降为 1 避免抢占，或混合 I/O 与密集计算时按阶段调优；日常服务保持默认最稳妥
慎用 runtime.Gosched：不是“让出 CPU”，而是“让出 P”
runtime.Gosched() 让当前 goroutine 主动放弃当前 P（逻辑处理器），回到全局队列等待下次调度。它不释放 OS 线程，也不触发系统调用，更不休眠——只是礼貌退场，把执行权交还调度器。
- 典型适用场景：手写无阻塞循环且无法拆分（如纯计算型轮询），防止长时间独占 P 导致其他 goroutine “饿死”
- 绝大多数情况不需要：IO 操作、channel 收发、time.Sleep、锁等待等都会自动让出 P；Go 1.14+ 的异步抢占机制也让长时间运行的 goroutine 更容易被中断
- 滥用后果明显：频繁调用 Gosched 增加调度切换次数，实际降低吞吐；它不能替代正确设计（如分块处理、使用 context 控制生命周期）
真正影响调度效率的，往往是这些被忽略的点
比起调参数，以下实践对调度健康度影响更大：
立即学习“go语言免费学习笔记（深入）”；
- 避免 goroutine 泄漏：未消费的 channel、忘记 close 的 timer、死循环中未设退出条件，会让 goroutine 积压，增大调度器负担
- 减少锁竞争：大量 goroutine 争抢同一 mutex，会导致它们排队等待、反复唤醒/挂起，调度器疲于奔命
- 慎用 runtime.LockOSThread：绑定线程后该 goroutine 失去调度灵活性，且关联的 M 无法复用，容易造成资源浪费
- 优先用 channel + select 控制并发流，而不是靠 Gosched 或 sleep 手动节流
基本上就这些。GOMAXPROCS 宜稳不宜躁，Gosched 宜少不宜滥。Go 调度器本身足够智能，与其微操，不如写好阻塞点、管住 goroutine 生命周期、让调度器安静干活。
