默认值为逻辑CPU核心数，即Go 1.5起GOMAXPROCS默认设为runtime.NumCPU()，反映可用逻辑核数（含超线程与cgroup限制），仅控制并行执行用户代码的P数量上限，不绑定物理核心，也不限制goroutine创建数量。
默认 P 数量等于机器的逻辑 CPU 核心数，但这只是启动时的初始值，不是硬绑定，也不代表“必须设成这个数才对”。
runtime.GOMAXPROCS 的实际作用范围
它只控制当前进程中可同时执行 Go 用户代码的 P 数量上限，不改变 CPU 物理结构，也不强制把某个 P 绑定到某颗核心上。操作系统仍全权决定线程 M 落在哪颗 CPU 上运行。
-
GOMAXPROCS设置的是“能并行跑用户态 Go 代码的调度上下文数量”，不是“能创建多少 goroutine” - 哪怕设为
1，你照样可以起百万个 goroutine；只是它们会排队等这唯一的P调度 - 设为
8并不保证 8 个核心满载——如果 goroutine 大量阻塞在 I/O 或 channel 上，P可能空转或频繁切换
为什么默认值选逻辑核心数
这是基于“避免线程级上下文切换开销”的经验性平衡点：在纯计算场景下，让每个 P 对应一个逻辑核心，基本能填满 CPU 吞吐能力，又不会因过度并发引入调度竞争。
- 四核八线程 CPU → 默认
GOMAXPROCS = 8，不是 4 - 容器中运行时，
runtime.NumCPU()返回的是宿主机核数，不是 cgroup 限制值，容易误判 - 若程序启动后才调用
runtime.GOMAXPROCS(n)，部分初始化逻辑（如init函数）已在旧 P 数下完成，无法回溯重调度
改了 GOMAXPROCS 却没效果的常见原因
多数时候性能无变化甚至下降，并非参数无效，而是你的瓶颈根本不在 P 数量上。
- 代码里大量用
time.Sleep()、sync.Mutex全局锁、或同步channel操作：这些不释放P，P 多了也干等 - I/O 密集型服务（如 HTTP API）设高了反而更差：netpoller 本就能异步处理等待，多
P增加调度器负载，trace 里常看到 “Scheduler latency” 突增 - 数据库连接池
maxOpen = 1或磁盘 I/O 单点串行：再多P也得排队，压测 QPS 不涨
怎么判断该设多少才合理
没有银弹公式，但有可落地的验证路径：
- 先用
go tool trace观察Proc status面板：看各P是否长期空闲（说明设多了），还是总有一堆G在GRQ排队（可能设少了） - 计算密集型任务：从
runtime.NumCPU()开始，逐步降低，看 CPU 利用率和 wall-time 是否变化 - 容器环境务必读取
/sys/fs/cgroup/cpu.max或cpu.cfs_quota_us来算实际可用配额，而非依赖NumCPU() - 别迷信“越高越好”——Go 调度器的 M:N 设计，本意就是用少量
P高效托起大量G，不是靠堆资源换性能
真正难的不是设哪个数字，而是识别出你的程序到底卡在哪一层：是调度器争抢？OS 线程阻塞？系统调用等待？还是业务逻辑里的隐式串行？GOMAXPROCS 只是其中一把钥匙，开错锁眼，再亮也没用。
