改了GOMAXPROCS没提速不是配置失效，而是调错地方：它只控制并行执行用户代码的P数量，不解决sleep、锁、channel阻塞、连接池瓶颈等问题；容器中须按cgroup配额设值，否则默认用宿主机核数导致争抢；不同workload需差异化设置，且必须通过trace/pprof验证真实瓶颈。
为什么改了 GOMAXPROCS 却没提速
不是配置失效，而是你调错了地方。它只管“有多少个逻辑处理器（P）能同时跑用户代码”，不管 goroutine 是否真在干活。
- 大量
time.Sleep()、sync.Mutex全局锁、或无缓冲channel阻塞：P 多了也得排队等，CPU 时间根本没释放 - 数据库连接池
maxOpen=1或 JSON 解析串行化：所有请求卡在同一临界区，GOMAXPROCS再大也无用 - 启动后才调
runtime.GOMAXPROCS(n)：init 阶段的 goroutine 已绑定旧 P，无法迁移 - HTTP 服务本身只是转发/轻量响应：多 P 反而抬高调度开销，
GOMAXPROCS(1)有时 p99 更低
容器里不设 GOMAXPROCS 就等于开错数
runtime.NumCPU() 在 Docker/K8s 里返回的是宿主机核数，不是你 Pod 的 vCPU 配额。比如宿主机 32 核、Pod limits.cpu: "500m"，默认开 32 个 P，结果是 32 个 P 抢 0.5 核，schedlat 拉高，QPS 下跌。
- 安全做法：启动时读
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，算quota / period得真实 vCPU 数 - 最简方案：用环境变量启动，比如
GOMAXPROCS=2 ./myserver，比代码硬编码更易灰度 - Go 1.19+ 可加
GODEBUG=schedtrace=1000观察日志是否出现auto-adjusting GOMAXPROCS
不同 workload 类型该设多少
GOMAXPROCS 不是“核数越多越好”，它控制的是并行执行用户代码的 P 数，选值必须匹配负载特征：
- CPU 密集型（图像转码、数值聚合）：从容器 vCPU 数起步，压测时看
go tool trace中 “Proc status” idle 占比，低于 10% 可尝试微增 - I/O 密集型（HTTP API、DB 中间层）：默认值通常最优；若延迟毛刺多，试
GOMAXPROCS(1)，减少 steal 和上下文切换 - 混合型（JSON 解析 + 外部 HTTP 调用）：先用默认值压测，再用
pprof看 CPU 热点——如果encoding/json占比高，才考虑上调
验证是否真生效、有没有副作用
别只信代码里写了 runtime.GOMAXPROCS(4)，得确认它真起作用，且没拖垮其他环节：
立即学习“go语言免费学习笔记（深入）”；
- 启动后立刻打日志：
fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0)) - 用
go tool trace打开 Scheduler 视图，检查 P 数量是否匹配，且 “idle” 时间不过长 - 压测对比：QPS 不变但 p99 延迟明显升高 → 很可能是
GOMAXPROCS过大导致runtime.mcall暴增 - 注意 GC 影响：值越大，mark worker 数越多，但若堆对象分布不均，反而延长 STW 时间
GOMAXPROCS 调得再准，也救不了没传 context.Context 的异步上报。 
