Go程序在容器中GOMAXPROCS仍为宿主机CPU数，是因为Go 1.14+虽默认自动调优，但若cgroup文件（v1/v2）未暴露或权限不足，便回退读取/proc/cpuinfo；automaxprocs通过早期主动读cgroup并设值来解决该问题。
Go 程序在容器里为啥 GOMAXPROCS 还是宿主机 CPU 数？
因为 Go 1.14+ 虽然默认启用 runtime.GOMAXPROCS(0) 自动调优，但它只看 /proc/sys/kernel/osrelease 和 /sys/fs/cgroup/cpu.max（cgroup v2）或 /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），而很多容器运行时（尤其是旧版 Docker 或未挂载完整 cgroup 的环境）压根没暴露这些文件，或者挂载了但权限受限，导致 Go 回退到读取 /proc/cpuinfo —— 那就是宿主机的核数。
常见错误现象：docker run -it --cpus=1 golang:1.22 go run main.go 启动后 runtime.GOMAXPROCS(-1) 返回 64（宿主机核数），不是 1；pprof 显示 goroutine 在多个 OS 线程上调度，CPU 使用率突破限制。
- 确认是否真在 cgroup v2 环境：检查
/proc/1/cgroup是否含0::/...格式路径；v1 是8:cpu:/docker/xxx - Go 1.21+ 才真正支持 cgroup v2 的
cpu.max解析；1.20 及之前只认 v1 - 即使 cgroup 正确，如果容器启动时没加
--cpus=或--cpu-quota/--cpu-period，Go 就无从感知限制
automaxprocs 库到底解决了什么问题？
它不是替代 runtime.GOMAXPROCS，而是「早于 runtime 初始化」就去读 cgroup 文件，并主动调用 runtime.GOMAXPROCS(n)。核心价值在于：绕过 Go 原生逻辑中对 cgroup 文件缺失的静默降级，强制按容器实际配额设值。
使用场景：Kubernetes Pod 里 CPU limit 设为 500m，但 Go 默认仍用 8 核（宿主机）；你希望 GOMAXPROCS 精确等于 ceil(0.5 * 逻辑 CPU 数)，而非拍脑袋写死 runtime.GOMAXPROCS(1)。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须在
main()最开头调用，比如func main() { automaxprocs.Set() }；放晚了，runtime 已初始化，再设无效 - 它会尝试读
/sys/fs/cgroup/cpu.max（v2）、/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1）、/sys/fs/cgroup/cpu/cpu.shares（仅作 fallback），最后才 fallback 到runtime.NumCPU() - 不处理 memory limit 感知 ——
automaxprocs只管 CPU，别指望它帮你调 GC 阈值
为什么直接改 GOMAXPROCS 环境变量不管用？
因为 GOMAXPROCS 环境变量只在进程启动时被 Go 运行时读取一次，且仅当未显式调用 runtime.GOMAXPROCS() 时生效。一旦代码里有任何地方调用了 runtime.GOMAXPROCS(n)（包括第三方库、test 初始化等），环境变量就被覆盖，且不可逆。
典型踩坑：Dockerfile 里写 ENV GOMAXPROCS=2，但 main 包 import 了某个内部工具库，该库 init 函数里执行了 runtime.GOMAXPROCS(runtime.NumCPU()) —— 结果还是宿主机核数。
- 用
strace -e trace=openat,read -f ./your-binary 2>&1 | grep cgroup确认程序是否真去读了 cgroup 文件 - 在容器内手动跑
cat /sys/fs/cgroup/cpu.max，看输出是不是100000 100000（表示无限制）或50000 100000（表示 0.5 核）；如果是max，automaxprocs会 fallback 到NumCPU() - Kubernetes 中若只设
resources.limits.memory没设 CPU，cgroup cpu 子系统可能根本没创建，automaxprocs也读不到任何限制
要不要在所有容器 Go 服务里都加 automaxprocs.Set()？
不是必须，但强烈建议 —— 尤其当你的服务有明确 CPU limit、且对调度延迟或 GC 停顿敏感时。它成本极低（一次文件读+一次 syscall），却能避免 Goroutine 被过度调度到闲置线程上，减少上下文切换开销。
注意点：如果你的应用本身做了精细的并发控制（比如固定启 2 个 worker goroutine），那 GOMAXPROCS 大小影响有限；但如果是高吞吐 HTTP 服务、大量 channel select 或 timer 操作，错配的 GOMAXPROCS 会让 netpoller 和 timer heap 调度效率明显下降。
- Go 1.22+ 的
runtime/debug.ReadBuildInfo()能查到是否启用了go:buildtag 影响调度器行为，但和 cgroup 无关 - 某些硬实时场景下，你可能反而要锁死
GOMAXPROCS=1避免抢占，这时automaxprocs就不该用 - 最易忽略的是：CI 构建环境（如 GitHub Actions runner）通常没 cgroup，
automaxprocs会 fallback 到NumCPU()，和本地开发一致；但上线到 K8s 后行为突变 —— 务必在 staging 环境验证 cgroup 读取结果
