GOMAXPROCS 设置无效通常因代码或第三方库覆盖了初始值，需检查所有 runtime.GOMAXPROCS 调用并用 runtime.GOMAXPROCS(0) 验证；容器中应基于 cgroup 限制而非 NumCPU() 动态计算合理值。
GOMAXPROCS 设置后没效果？先确认 runtime.GOMAXPROCS 是否被覆盖
容器里改了 GOMAXPROCS 但 CPU 利用率还是低、goroutine 调度卡顿，大概率是代码里某处调用了 runtime.GOMAXPROCS 覆盖了启动时设置。Go 程序启动后，GOMAXPROCS 是可变的，且没有只读保护。
- 检查所有
import "runtime"的地方，搜runtime.GOMAXPROCS调用 - 第三方库（比如某些 metrics agent、tracing SDK）可能在 init 阶段偷偷设值，加个
fmt.Println(runtime.GOMAXPROCS(0))在 main 开头验证实际值 - 容器启动命令中用
GOMAXPROCS=4环境变量，和代码里runtime.GOMAXPROCS(2)冲突时，后者胜出
容器限制下 GOMAXPROCS 应该设多少？别直接用 runtime.NumCPU()
runtime.NumCPU() 返回的是宿主机 CPU 核心数，不是容器 cgroup 限制值。Kubernetes 或 Docker 通过 cpu.shares、cpu.quota/cpu.period 或 cpuset 限制可用 CPU，Go 默认不知道这些。
- 优先读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us计算配额核数（如 quota=-1 表示不限，此时再 fallback 到NumCPU()） - 若容器使用
cpuset（如--cpusets-cpus="0-1"），应解析/sys/fs/cgroup/cpuset/cpuset.effective_cpus - 简单场景下可用
os.Getenv("GOMAXPROCS")+ 启动前校验，避免硬编码
Docker/K8s 中环境变量 GOMAXPROCS 不生效？检查 Go 版本和镜像基础
Go 1.5+ 支持环境变量 GOMAXPROCS 自动生效，但前提是程序启动前该变量已存在——如果用 shell wrapper 启动、或 entrypoint 是 bash 脚本且未用 exec，Go 进程可能拿不到。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Alpine 镜像常见问题：musl libc 下部分 cgroup 文件路径不同（如
/sys/fs/cgroup/cpu.max替代旧路径），Go 1.19+ 才原生支持 - K8s 中若设置了
resources.limits.cpu: "1500m"，它不等于 1.5 核调度能力，cfs_quota_us 可能为 150000，period 为 100000 → 实际等效核数 = 1.5，但需自己算 - 用
go version确认镜像内 Go 版本，低于 1.5 的镜像必须代码里显式调用runtime.GOMAXPROCS
高并发小对象场景下调大 GOMAXPROCS 反而更慢？注意 P 与 OS 线程竞争
不是越大越好。GOMAXPROCS 控制的是“P”（Processor）数量，每个 P 绑定一个 OS 线程（M）。当 P 数远超物理核数，会引发线程上下文切换开销、cache line bouncing、调度器自旋等待等问题。
立即学习“go语言免费学习笔记（深入）”；
- IO 密集型服务（如 HTTP API）可适当高于核数（如 1.2–1.5×），但超过 2× 通常收益递减
- CPU 密集型计算（如图像处理、加密）建议 ≤ 物理核数，避免虚假共享和 TLB 压力
- 用
go tool trace观察Scheduler视图中的 “Preempted” 和 “Syscall” 占比，若 Preempted 高，说明 P 太多导致频繁抢占
最常被忽略的一点：容器里 GOMAXPROCS 设对了，但应用本身有全局锁、串行 channel 或低效 sync.Pool 使用，性能瓶颈根本不在调度器——调参前先 pprof cpu 看真实热点。
