Go模块系统仅负责编译期依赖管理，不参与运行时调度；真正实现多核自适应的是runtime内置的GMP模型，其P数量由GOMAXPROCS控制，默认等于CPU核心数。
Go 模块本身不参与调度，也不“动态扩容”——真正能自适应多核的是 runtime 的 GMP 模型，而模块（module）只是代码组织和依赖管理单位。你写的 go.mod 文件不会影响 CPU 利用率，也不会让 goroutine 自动分到更多 P 上。
为什么改 go.mod 对多核调度完全没用
模块系统负责版本解析、依赖下载和构建隔离，它在编译期就结束了工作。运行时调度器根本不知道你的代码来自哪个 module，go run 启动后，所有包被统一加载进同一个地址空间，调度器只看 G、P、M 状态和当前可运行队列。
-
go mod tidy不会增加或减少 goroutine 数量，也不会触发新线程创建 - 升级一个依赖（比如从
v1.2.0到v1.3.0）若该版本内部用了更多 channel 或更细粒度的go调用，才可能间接影响并发行为——但这是代码逻辑变化，不是模块机制本身的作用 - 模块缓存（
$GOPATH/pkg/mod）只加速构建，不参与运行时调度决策
runtime.GOMAXPROCS 是唯一能影响 P 数量的开关，但通常不该动
默认值就是机器逻辑 CPU 核心数，runtime.GOMAXPROCS(0) 返回的值就是当前生效的 P 数。手动设高了，在容器里会引发调度抖动；设低了，又浪费资源。
- 只有混部环境（如
docker run --cpus=2）才需显式设为对应值，否则让 Go 自己读/sys/fs/cgroup/cpu/cpu.cfs_quota_us -
GOMAXPROCS改变的是 P 的数量，不是 OS 线程数；M 可以复用，P 才是并行上限的硬约束 - 调整后不会立即生效，会在下一个调度点（比如一次
syscall返回或chan操作完成）才重新分配 G
真正决定多核利用率的，是你的代码怎么写
goroutine 多 ≠ 并行多。调度器只能帮你分发，不能替你拆任务。常见卡点有：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 同步阻塞：比如
http.Get未配超时、database/sql连接池太小，导致大量 G 堵在net.(*pollDesc).wait - 锁竞争：
sync.Mutex被高频争抢时，runtime.futex占比飙升，P 在等唤醒，CPU 空转 - 纯计算无让出点：for 循环里没调
runtime.Gosched()或 I/O，Go 1.14+ 虽有抢占，但仅限编译器插入的协作点，不是实时强制切换 - channel 使用不当：无缓冲 channel 发送/接收必须配对，否则一方挂起，M 被占住，其他 G 饿死
想验证是不是调度器的问题？先跑 go tool trace 和 pprof
别猜，直接看数据。启动时加 -gcflags="-l" -ldflags="-s -w" 减少干扰，再开 net/http/pprof 端点。
-
go tool trace里重点看 “Proc Status” 图：如果多个 P 长时间处于Idle状态，但 CPU 利用率低，说明不是调度器没干活，而是没活干——代码没产生足够可并行的 G -
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30后输入top -cum：看到runtime.mallocgc高？说明你在高频创建 slice/map，该用sync.Pool或预分配；看到sync.(*Mutex).Lock排前三？说明锁成了瓶颈 - 注意区分
goroutines数量（runtime.NumGoroutine()）和活跃 G 数——大量 G 处于chan receive或select等待态，并不消耗 CPU
调度器从不“自适应扩容”，它只响应你提交的 G 和它们的阻塞/就绪状态。所谓“动态”，其实是你代码触发了更多可并行路径，而不是某个配置开关打开了什么魔法功能。
