必须显式设置GOMAXPROCS，依据容器实际CPU配额（如cfs_quota_us/cfs_period_us）向上取整计算，而非宿主机核数；需在main开头调用runtime.GOMAXPROCS()，并配合goroutine并发控制。
Go 程序默认会把 GOMAXPROCS 设为宿主机逻辑 CPU 核心数，但在容器或 Kubernetes 环境中，这往往远超实际可分配的 CPU 资源，导致调度争抢、上下文切换飙升、延迟毛刺明显。必须显式设置，且不能只看 runtime.NumCPU()。
怎么查当前 GOMAXPROCS 值
运行时只读查询用 runtime.GOMAXPROCS(0)，返回当前生效值。别在日志里打 runtime.NumCPU() —— 它返回的是宿主机核数，和容器限制无关。
- 在程序启动早期加一行：
log.Printf("GOMAXPROCS=%d, NumCPU=%d", runtime.GOMAXPROCS(0), runtime.NumCPU()) - 如果两者差很多（比如 GOMAXPROCS=32，NumCPU=32，但容器
cpu limit: 500m），说明没设对 - 调试时也可用
go tool trace查看“Proc”数量是否与预期一致
在容器中怎么设才对
Kubernetes 的 resources.limits.cpu（如 500m）是 CFS 配额，不是核数。得把它换算成等效逻辑核数再设 GOMAXPROCS，否则调度器仍按 32 核跑 32 个 P，但 OS 只给 0.5 核时间片，结果就是大量 goroutine 饥饿等待。
- 推荐做法：启动前读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，算出可用核数 = quota / period（如 50000 / 100000 = 0.5）→ 向上取整为 1 - 更稳妥的 fallback：用
cpuset检查/sys/fs/cgroup/cpuset/cpuset.effective_cpus，直接数可用 CPU ID 个数 - 简单但不推荐的兜底：设环境变量
GOMAXPROCS=1或GOMAXPROCS=2，适用于小规格容器
runtime.GOMAXPROCS() 调用时机和副作用
必须在 main() 开头、任何 goroutine 启动前调用；晚了可能部分 P 已初始化，再调也不会回收旧 P，只新增或缩容新 P，造成资源错配。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
go func(){ runtime.GOMAXPROCS(2) }()—— 完全无效 - 正确位置：就在
import之后、var wg sync.WaitGroup之前 - 设为 0 是合法的，表示“恢复为当前系统可用核数”，但容器里依然不准——它读的还是宿主机
- 设得过小（如 1）会导致纯计算任务串行化；设得过大（如 64）在 2 核容器里会引发剧烈调度抖动
要不要配合 goroutine 并发数控制
设对 GOMAXPROCS 只解决了“P 层并行度”，但业务层若无节制起 goroutine（比如 HTTP handler 里 for 循环 go f()），照样压垮内存和调度器。这两者必须配合。
- 高吞吐服务建议用
golang.org/x/sync/semaphore控制并发 goroutine 数，上限建议设为GOMAXPROCS × 2 ~ × 4（I/O 多就高些，计算多就低些） - 避免用
time.Sleep或空循环做“限流”，它们不释放 P，会卡死其他 goroutine - 批量任务优先分片 + 固定 worker 数，而不是每个 item 起一个 goroutine
真正难的不是“怎么设”，而是确认你设的那个数字，到底对应容器里哪几个 CPU 时间片。/sys/fs/cgroup 下的文件不会骗人，但很多人连进容器 ls /sys/fs/cgroup 都忘了试。
