协程调度器是go运行时内置的gmp模型，应用无法直接修改；所谓“调优”实为控制goroutine行为以规避瓶颈。runtime.gomaxprocs仅设p数量，不控goroutine总数或调度时机，设高易引发m争抢抖动，默认值已最优；goroutine泄漏比调度慢更致命，会耗尽内存与文件描述符。
协程调度器不是框架层能“调优”的东西——它是 Go 运行时（runtime）内置的 GMP 模型，应用代码无法直接修改其调度逻辑。所谓“调优”，本质是控制 Goroutine 行为、规避调度瓶颈，而不是去动 runtime.scheduler。
为什么 runtime.GOMAXPROCS 不等于并发上限
runtime.GOMAXPROCS 只控制 P（Processor）数量，即最多有多少个 OS 线程能同时执行 Go 代码；但它不约束 Goroutine 总数，也不决定谁被调度、何时切换。盲目设高会导致 P 频繁抢 M（OS 线程），反而加剧上下文切换抖动。
- 默认值已是
runtime.NumCPU()，多数场景无需改动 - 设为 1 会强制串行执行（仅调试用），但 HTTP server 等阻塞型服务可能卡死在 syscalls 上
- 云环境（如容器）中，
GOMAXPROCS应匹配 cgroup CPU quota，否则 P 争抢超配的 M
goroutine 泄漏比调度慢更致命
调度器本身能扛住 10 万+ Goroutine，但泄漏的 Goroutine 会长期持有栈内存、channel 引用、timer、net.Conn 等资源，最终耗尽内存或文件描述符——这常被误判为“调度器卡顿”。
- 典型泄漏模式：
go func() { ch 向已满/关闭的 channel 发送，Goroutine 永久阻塞在 <code>send状态 - HTTP handler 中启动 goroutine 但没传
context.Context，请求 cancel 后 goroutine 仍运行 - 使用
time.After在循环里创建 timer，未 stop 导致 timer leak - 用
pprof查/debug/pprof/goroutine?debug=2，重点关注状态为chan send或select的 Goroutine
协程池不是银弹，要分场景选实现
协程池真正解决的是“任务突发 + 资源受限”组合问题，比如批量写日志、消费消息队列、限流下游 HTTP 请求。它不适用于 CPU 密集型长任务（会饿死其他 goroutine）或纯 I/O 等待型操作（Go runtime 已自动让出 M）。
- 用
ants库时，注意ants.WithNonblocking(true)会让超载任务直接丢弃，而非排队——需配合重试或降级逻辑 - 手动实现池时，worker goroutine 必须用
recover()捕获 panic，否则整个池会因单个 panic 崩溃 - 池大小 ≠ CPU 核心数：I/O 型任务池可设为 50~200；数据库连接池则必须 ≤ 连接池最大连接数
- 别把
sync.Pool当协程池用——它只缓存对象，不管理 goroutine 生命周期
最易被忽略的一点：调度器优化永远排在业务逻辑之后。先确保没有无意义的 goroutine 创建（比如每个 HTTP middleware 都起一个 goroutine）、channel 无缓冲却无接收者、timer 未 stop，再谈 GMP 参数或协程池——否则所有“调优”都在给泄漏兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
