runtime.GOMAXPROCS不是提速开关，仅控制同时执行用户代码的P数量；默认值自Go 1.5起已是runtime.NumCPU()，多数场景无需手动设置，且必须在main开头或启动时通过环境变量配置，否则无效。
runtime.GOMAXPROCS 不是用来“提速”的开关，它只控制 Go 调度器中能同时执行用户代码的逻辑处理器（P）数量。默认值在 Go 1.5+ 就已是 runtime.NumCPU()，绝大多数场景下你根本不需要手动调用它。
为什么刚写完 runtime.GOMAXPROCS(runtime.NumCPU()) 就报错或没效果
这不是语法错误，而是逻辑误用：Go 1.5 起该调用已自动完成，硬编码等于重复设置；更关键的是，runtime.GOMAXPROCS(n) 必须在程序早期（main 函数开头、甚至 init 阶段前）调用才有效——包级变量初始化、init 函数执行时已绑定到旧的 P 上，之后再改不会回溯重调度。
- 常见现象：启动后打印
runtime.GOMAXPROCS(0)发现仍是旧值，说明调用太晚 - 典型坑点：把
runtime.GOMAXPROCS放在某个 HTTP handler 里，完全无效 - 正确时机：只在
main()最开头，或通过环境变量启动时控制
容器里 runtime.NumCPU() 返回宿主机核数，怎么办
在 Docker/Kubernetes 中，runtime.NumCPU() 读的是宿主机逻辑核数，不是 cgroup 限制的 vCPU 数。比如宿主机 64 核、容器 resources.limits.cpu: "2"，Go 默认起 64 个 P，结果所有 goroutine 挤在少数 OS 线程上争抢，schedlat 持续 >100µs。
- 验证方式：运行时读
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，算出实际配额（quota / period） - 推荐做法：用环境变量
GOMAXPROCS=2启动，而非代码里硬编码 - Go 1.19+ 可加
GODEBUG=schedtrace=1000观察是否触发 auto-adjusting 提示
调大 GOMAXPROCS 反而让 p99 延迟飙升，为什么
它不增加吞吐能力，只改变调度粒度。盲目设高会放大调度开销：上下文切换激增、runtime.mcall 和 runtime.gopark 调用暴涨、GC mark worker 分配失衡拉长 STW 时间。
立即学习“go语言免费学习笔记（深入）”；
- IO 密集型服务（如 HTTP API）通常
GOMAXPROCS=1或默认值就足够，多 P 只增竞争不增收益 - 纯计算任务才值得试探调高，但也别超过物理核数（非逻辑核）
- 真有瓶颈时，先看
go tool trace的 Scheduler 视图：是否持续出现 P 饥饿、M 阻塞，再决定是否调
真正卡性能的地方，90% 不是 GOMAXPROCS，而是数据库连接池过小、channel 同步阻塞、JSON 解析锁全局、或没做连接复用。调这个参数前，先跑一遍 go tool pprof -http=localhost:8080 binary 看热点在哪。
