gin.default() 不会自动适配容器 cpu 核心数，因为它仅初始化路由引擎并挂载中间件，不干预 runtime.gomaxprocs 设置；go 运行时虽从 1.14 起支持 cgroup 感知并自动调整 gomaxprocs，但该行为依赖启动时环境配置，gin 本身无感知能力。
为什么 gin.Default() 不会自动适配容器 CPU 核心数
Gin 本身不感知运行环境是否为容器，gin.Default() 只是初始化一个路由引擎并挂载 Logger 和 Recovery 中间件，它不启动任何 goroutine 池、不设置 runtime.GOMAXPROCS、也不读取 cgroup 限制。Go 运行时默认会将 GOMAXPROCS 设为系统逻辑 CPU 数（即 numcpu），但在容器中若未显式限制，它仍可能读到宿主机总核数，导致过度调度或资源争抢。
容器内 Go 程序的 GOMAXPROCS 实际行为
从 Go 1.14 起，运行时已支持自动检测 cgroup v1/v2 的 cpu.max 或 cpu.cfs_quota_us 配置，并据此调整 GOMAXPROCS —— 但该机制仅在程序启动时生效，且依赖底层内核和 runtime 协同。你不能靠 Gin 控制它，而应确保：
- 容器启动时通过
--cpus=2或resources.limits.cpu: "2"显式设限（Kubernetes） - 避免手动调用
runtime.GOMAXPROCS(n)，除非你有明确压测结论证明需覆盖自动逻辑 - 验证是否生效：在 handler 中打印
runtime.GOMAXPROCS(0)和runtime.NumCPU()，前者应 ≤ 后者，且接近容器实际分配核数
gin.Run() 启动的是单个 HTTP server，不是多进程模型
Gin 的 r.Run() 底层调用的是 http.Server.Serve()，它复用 Go 标准库的 net/http 服务器，完全基于 goroutine 并发，不 fork 进程、不绑定 CPU 绑核（taskset）、也不做 worker 进程管理。这意味着：
- 横向扩展靠 Kubernetes Deployment 的 Pod 副本数，而非单个 Gin 进程“多核并发”
- 单个 Gin 实例天然能跑满分配给它的所有 CPU 时间片，无需额外适配逻辑
- 若观察到 CPU 利用率低但请求延迟高，问题大概率出在阻塞操作（如未加 context 的 DB 查询、同步文件 I/O），而非核心数配置
真正需要关注的容器适配点：健康检查与信号处理
微服务容器化后，Gin 服务能否被正确探活、优雅退出，比“核心数适配”更关键：
- Kubernetes
livenessProbe应指向轻量端点（如/healthz），避免触发中间件链或 DB 连接池初始化 - 必须监听
os.Interrupt和syscall.SIGTERM，调用srv.Shutdown()关闭 server，否则容器stop时会强制 kill，导致连接中断、事务丢失 - 不要在
gin.Context中存储跨请求的全局状态（如缓存 map），容器弹性伸缩时实例生命周期不可控
容器里 Gin 服务的性能瓶颈几乎从来不在“用了几个核”，而在于数据库连接池大小、HTTP 客户端超时设置、中间件是否阻塞、以及日志是否同步刷盘——这些才是上线前必须逐项核对的点。
