GOMAXPROCS不是并发加速器，它仅控制同时执行用户代码的P数量；设高后QPS卡住是因为goroutine大量阻塞在I/O（如syscall、chan receive），P被占用却未执行用户代码，再多P也无济于事。
runtime.GOMAXPROCS 不是并发加速器，它只控制同时执行 Go 用户代码的 OS 线程数（即 P 的数量），设高了反而容易拖慢程序。
为什么 GOMAXPROCS 设高了 QPS 反而卡住
常见现象：runtime.GOMAXPROCS(4) 启动后 top 显示 CPU 使用率仅 20%～30%，压测 QPS 上不去，pprof 却显示大量 goroutine 处于 syscall 或 chan receive 状态。
根本原因不是调度器没干活，而是这些 goroutine 正在等：文件读写、DNS 查询、数据库响应、channel 阻塞、未设 timeout 的 HTTP 调用 —— 此时 P 被占着但没执行用户代码，再多线程也无济于事。
- 优先查阻塞源头：用
go tool trace看 “Sched” 视图里灰色（阻塞）时间段是否密集 - 用
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'看堆栈是否集中在read、net.Conn.Read或select上 - 确认是否真有 CPU 密集瓶颈：
go tool pprof -cpu看火焰图里runtime.mcall或runtime.park占比是否异常高
容器环境下 runtime.GOMAXPROCS 必须与 vCPU 配额对齐
runtime.NumCPU() 在容器内返回的是宿主机逻辑核数，不是 cgroups 限制值。
立即学习“go语言免费学习笔记（深入）”；
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
典型错误：Docker 启动加了 --cpus=2，但 Go 程序仍调用 runtime.GOMAXPROCS(runtime.NumCPU())，结果返回 32，导致线程争抢、cache false sharing 加剧。
- 启动时优先用环境变量：
GOMAXPROCS=2 ./myserver - Kubernetes 中，在 Deployment 的
env里显式设置GOMAXPROCS=2 - 若必须代码中设，改用
os.Getenv("GOMAXPROCS")解析后转为int再调用runtime.GOMAXPROCS(n)，避免 fallback 到NumCPU() - 验证是否生效：启动后立刻打印
runtime.GOMAXPROCS(0)，并用go tool trace确认 Scheduler 视图中 P 的数量匹配
什么时候真该调 GOMAXPROCS，而不是默认就行
绝大多数 I/O 密集型服务（如 API 网关、日志转发）不需要调大，runtime.GOMAXPROCS(2) 甚至默认值就够用。
真正值得调整的场景很窄，且必须可观测：
-
pprof的goroutineprofile显示大量 goroutine 长时间处于runnable状态 -
go tool trace的 Scheduler 视图中出现持续的 M 阻塞或 P 饥饿 - 单机部署多个 Go 进程，每个都默认用满所有核 → 应按进程数均分，比如 8 核跑 4 个服务，每个设
runtime.GOMAXPROCS(2) - 混合部署 Java/Go 服务，Java 用了
-XX:ParallelGCThreads锁定线程数，Go 侧需让出部分核心
最常被忽略的一点：修改 runtime.GOMAXPROCS 必须在 main() 开头完成，不能在 goroutine 里调用，也不能在 init 函数之后、main 之前被并发修改 —— 否则行为未定义。
