Go 1.25 runtime.SetDefaultGOMAXPROCS 调整后怎么验收：容器 CPU 配额与调度行为

升级到 Go 1.25 后，运行在 Linux 容器里的服务可能不再把宿主机逻辑 CPU 数量直接当作默认并行度，而是结合 cgroup CPU 配额计算 GOMAXPROCS。若旧服务曾经通过环境变量或 runtime.GOMAXPROCS 固定过并行度，升级后还要用 runtime.SetDefaultGOMAXPROCS 明确恢复运行时默认值，并用容器内的可见状态完成验收。

迁移的关键不是盲目把 GOMAXPROCS 改成某个数字，而是先移除旧的人工覆盖，再验证 CPU limit、GOMAXPROCS 和延迟表现是否符合部署约束。

升级范围：默认并行度从哪里来

Go 1.25 的变化集中在默认 GOMAXPROCS，而不是改变 goroutine 的语义。Linux 进程启动时，运行时会综合逻辑 CPU 数量、CPU affinity 和 cgroup CPU quota；当 quota 更低时，默认值会向容器的 CPU limit 靠拢。小数配额需要转换成正整数，运行时会向上取整以覆盖完整的平均吞吐额度。

这和 Kubernetes 的 CPU request 不是一回事：request 是调度保证和资源权重，limit 才通常对应 cgroup 的 CPU bandwidth limit。没有 CPU limit 的容器，不能期待 GOMAXPROCS 自动等于 request。

旧代码风险：人工覆盖会遮住新默认值

先在代码和部署清单里搜索三类覆盖：GOMAXPROCS 环境变量、runtime.GOMAXPROCS 调用以及关闭默认机制的 GODEBUG。只要服务仍保留这些设置，容器配额变化就可能不会反映到运行时。

package main

import (
    "fmt"
    "runtime"
)

func main() {
    fmt.Println("before:", runtime.GOMAXPROCS(0))
    runtime.SetDefaultGOMAXPROCS()
    fmt.Println("after:", runtime.GOMAXPROCS(0))
}

这里的 runtime.GOMAXPROCS(0) 只读取当前值，不会主动重算；runtime.SetDefaultGOMAXPROCS() 才会忽略 GOMAXPROCS 环境变量并按运行时默认规则更新。它适合在应用确认 CPU affinity 或 cgroup quota 发生变化、又希望立即重算时使用。

新写法：把部署约束交给运行时

如果服务没有业务理由固定并行度，建议删除启动脚本中的 GOMAXPROCS，也不要在初始化阶段调用 runtime.GOMAXPROCS 写死宿主机核数。让默认规则负责初始值和周期更新；只有确实需要人工策略时，才把覆盖理由写进部署文档和验收项。

# Deployment 的关键片段：limit 是配额，request 不是 GOMAXPROCS 的输入
resources:
  requests:
    cpu: "500m"
  limits:
    cpu: "2"

# 不要在同一个容器里再设置 GOMAXPROCS=8

若历史初始化逻辑必须保留，可以把恢复默认行为的动作集中到一处，避免不同包分别修改并行度。对于升级期间需要对照实验的服务，还应明确记录 GODEBUG=containermaxprocs=0 或 GODEBUG=updatemaxprocs=0 是否存在，避免把实验配置带入生产。

回归检查：从数值到调度表现

验收至少分三层。第一层确认容器实际看到的 CPU limit 与部署清单一致；第二层在没有人工覆盖的进程里打印 runtime.GOMAXPROCS(0)，对照配额和逻辑 CPU 数量；第三层观察 CPU throttling、请求尾延迟和 GC 期间的峰值。不要只因为某次打印出了预期数字，就断定所有负载都更快。

fmt.Println("NumCPU:", runtime.NumCPU())
fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))

容器 CPU limit 改变后，Go 1.25 会周期性检查并更新默认 GOMAXPROCS；如果服务有长连接或稳定流量，应在配额调整前后观察一段完整的业务窗口。对尖峰明显的服务，较低的并行度可能减少 throttling，但也可能改变短任务的峰值吞吐，最终要以业务延迟和错误率判断。

迁移清单：上线前留下可复查证据

• go.mod 已切换到 Go 1.25 或更高版本，并确认构建镜像中的实际 go version。
• 部署清单中的 CPU limit、request 和 GOMAXPROCS 覆盖项已经分别记录。
• 未设置人工覆盖时，记录 NumCPU、GOMAXPROCS 和配额的同一时间点结果。
• 若使用 runtime.SetDefaultGOMAXPROCS，测试了环境变量覆盖、配额变化和回滚路径。
• 用 CPU throttling、P95/P99 延迟、GC 和错误率完成升级前后对照。

常见问题

CPU request 会让默认 GOMAXPROCS 变小吗？

不会直接参与 Go 1.25 的默认计算。应先确认容器是否配置了 CPU limit，以及 Linux cgroup 是否让进程能读到对应 quota。

已经调用 runtime.GOMAXPROCS 了，还会自动更新吗？

人工调用会关闭这套自动更新路径。若要恢复运行时默认值，可在确认没有其他并发初始化修改后调用 runtime.SetDefaultGOMAXPROCS。

默认值变小就一定更快吗？

不一定。它可能减少 CPU throttling 和尾延迟抖动，也可能限制突发并行度。必须结合实际负载、配额和延迟指标验收。

总结

Go 1.25 的容器感知 GOMAXPROCS 解决的是默认并行度与 CPU limit 脱节的问题。迁移时先清理旧覆盖，再用 runtime.SetDefaultGOMAXPROCS 处理明确的重算需求，最后把容器资源、运行时数值和业务指标放在同一份回归证据里，升级才可复查、可回滚。