Go 1.5+ 默认 GOMAXPROCS=NumCPU()，通常无需手动设置；盲目调高会加剧调度竞争、延迟上升和 GC 效率下降，应结合 workload 类型、cgroup 限额及 trace/pprof 数据动态调优。
绝大多数情况下，你不需要手动设置 runtime.GOMAXPROCS —— Go 1.5+ 默认已是 runtime.NumCPU()，直接生效。 盲目调高反而引发调度延迟上升、runtime.mcall 暴涨、GC 效率下降。真正要优化的，是识别它“该不该动”以及“动了是否真起作用”。
为什么改了 GOMAXPROCS 却没效果
这不是配置失败，而是你误判了瓶颈所在。常见无效场景：
- 代码里大量用
time.Sleep()、sync.Mutex全局锁，或channel同步阻塞：P 多了也得排队等，不释放 CPU 时间 - 数据库连接池
max=1或 JSON 解析串行化：并发请求全卡在同一个临界区，GOMAXPROCS再大也无济于事 - 启动后才调用
runtime.GOMAXPROCS(n)：部分init函数和包级变量已在旧 P 下初始化，调整不回溯 - HTTP 服务本身不耗 CPU（纯转发/轻量响应）：多 P 反而增加调度竞争，
GOMAXPROCS(1)有时更稳
容器环境里必须手动适配 GOMAXPROCS
runtime.NumCPU() 返回的是宿主机逻辑核数，不是容器实际能用的 vCPU。Kubernetes 中 resources.limits.cpu: "2" 是软限，但 Go 默认仍开 64 个 P，导致 goroutine 在少数 OS 线程上争抢，schedlat 持续 >100µs。
- 验证真实可用核数：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us，再算quota / period - Go 1.19+ 可启用自动适配：
GODEBUG=schedtrace=1000启动，观察日志是否含auto-adjusting GOMAXPROCS - 手动适配优先读 cgroup 文件，而非硬编码或依赖
resources.limits.cpu值（burst 行为会让除法结果失真） - 环境变量方式最安全：
GOMAXPROCS=2 ./myserver，比代码写死更易配置化
不同 workload 类型的推荐值
GOMAXPROCS 控制的是“能同时执行用户代码的逻辑处理器（P）数量”，不是并发任务数，也不影响 netpoller 或 channel 行为。选值取决于真实负载特征：
- CPU 密集型（数值计算、图像批处理）：从
runtime.NumCPU()起步，压测时观察go tool trace中 “Scheduler latency” 和 “Proc status” 是否出现 P 饥饿 - I/O 密集型（HTTP API、DB 查询为主）：默认值通常最优；极端情况可试
GOMAXPROCS(1)，减少调度竞争，反而降低 p99 延迟 - 混合型（JSON 解析 + DB 调用）：先用默认值压测，再结合
pprof分析 CPU 热点，判断是否需下调（如设为核数的 0.7 倍）
真正容易被忽略的点是：它只在程序启动时决定 P 的初始数量，后续动态调整虽可行，但无法重放已初始化的 goroutine 调度路径；而多数性能问题根本不在调度层，而在锁、IO、内存分配这些地方。别一看到 QPS 上不去就改 GOMAXPROCS，先 go tool trace 看一眼 “Proc status” 图里有没有红条（P blocked），再查 pprof 的 CPU profile 里是不是卡在 sync.(*Mutex).Lock 或 encoding/json.(*decodeState).object 上。
