GOMAXPROCS 不是 Gin 配置项，而是控制 Go 调度器逻辑处理器（P）数量的运行时参数；设错会导致 QPS 下降、调度延迟升高，I/O 密集型服务（如 Gin）应优先按容器 CPU 配额设置，并在 main 开头调用。
GOMAXPROCS 不是 Gin 的配置项，也不是“开得越大越快”的性能开关；它控制的是 Go 运行时能并行执行用户代码的逻辑处理器（P）数量，而 Gin 本身不干预这个底层调度——配错反而让 QPS 下跌、schedlat 拉高。
容器里 runtime.NumCPU() 返回的是宿主机核数，不是你 Pod 的 CPU 配额
你在 Kubernetes 中给服务设了 resources.limits.cpu: "2"，但 Go 启动时调用 runtime.NumCPU() 得到的可能是宿主机的 32 核。默认就会开 32 个 P，结果 32 个逻辑处理器抢 2 个 vCPU，线程切换暴涨，go tool trace 里能看到大量 P 处于 idle 但 runnable goroutine 堆积。
- 别信
docker stats或kubectl top pod显示的 CPU 使用率——那是过去 10 秒均值，不能当 GOMAXPROCS 设置依据 - 优先用环境变量：Docker 启动时加
-e GOMAXPROCS=2，K8s Deployment 里写进env字段，确保在 Go 运行时初始化前生效 - 如果必须代码里读取，别用
runtime.NumCPU()，改读 cgroup 文件：/sys/fs/cgroup/cpu.max（cgroup v2）或/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），再除以cpu.cfs_period_us
HTTP API 服务设太高反而降低吞吐，I/O 密集型建议从 1 开始压测
Gin 处理 HTTP 请求本质是 I/O 密集型：接收请求 → 解析 body → 调外部服务 → 序列化响应。goroutine 大量时间卡在 net.Conn.Read、http.Transport.RoundTrip 或 select 上，这些不消耗 CPU，也不需要更多 P 来“并行”。多 P 只会增加 steal 成本和负载均衡抖动。
- 纯计算型（如图像缩放、JSON 批量解析）可设为容器 CPU 配额值
- 混合型（Gin + gRPC 调用 + DB 查询）建议先设为配额值，再用
go tool trace观察 “Proc status” 页中 idle 时间占比：若长期 >70%，说明 P 过剩 - 设成
runtime.NumCPU() * 2或os.Getenv("CPU_LIMIT")未转整数——Go 不校验，但会导致调度器疯狂 steal，pprof里scheduler相关采样占比飙升
必须在 main() 最开头调用，晚了就失效
runtime.GOMAXPROCS(n) 必须在任何 goroutine 启动前完成。Gin 的 http.ListenAndServe 内部会立即启一个 goroutine 监听连接，一旦它跑起来，部分 goroutine 就已绑定旧 P 配置，后续修改无法回溯。
- 错误写法：
http.HandleFunc(...); runtime.GOMAXPROCS(2); http.ListenAndServe(...)—— handler 注册不触发 goroutine，但ListenAndServe一调就晚了 - 正确顺序：导入
runtime→runtime.GOMAXPROCS(2)→ 再做路由注册、中间件加载、ListenAndServe - 设为 0 会恢复为
runtime.NumCPU()；设负数直接 panic，日志里出现runtime: panic before malloc heap initialized
真正卡住 Gin 性能的，90% 是 http.Server 超时没设、http.Client 连接池复用没开、context 没传到底层调用，而不是 GOMAXPROCS。它只是调度器的“并发许可数”，不是魔法加速器——调之前先跑一次 curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'，搜 net.Conn.Read 占比，再决定要不要动它。
