Go 运行时并未实现 M:N 调度模型，M 和 N 之间不存在固定比例关系；调度围绕 P 的队列与 G 的就绪状态进行，M 数量动态增减，P 数量由 GOMAXPROCS 控制，G 在系统调用中与 M、P 解耦。
Go 里没有真正实现 M:N 调度模型，所谓“M 个 goroutine 映射到 N 个系统线程”只是运行时负载下自然呈现的数量关系，不是设计契约，也不是调度策略。
为什么 grep -r "M:N" runtime/src/runtime 找不到任何结果
因为 Go runtime 源码中根本不存在“维护 M:N 比例”的逻辑。调度主干函数 schedule()、findrunnable()、execute() 全部围绕 P 的队列状态和 G 的就绪性做判断，不查 M 数量，也不管 N 是多少。所谓“M:N”是外部观察者对现象的误读，不是运行时的行为准则。
GOMAXPROCS 控制的是 P 的数量，不是“N”的上限
GOMAXPROCS 设置的是活跃 P 的个数（默认等于 CPU 核数），它决定了并行执行 goroutine 的逻辑处理器上限。M 的数量则完全动态：遇到阻塞系统调用时，runtime 会按需创建新 M；空闲 M 在休眠一段时间后会被回收。M 和 P 之间是临时绑定关系，不是固定配对。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 设置
GOMAXPROCS=1并不会限制 goroutine 总数，只是让所有可运行 G 都排队在一个 P 上 - 即使
GOMAXPROCS=1，runtime 仍可能启动数十个 M 来处理阻塞型系统调用（如read()、accept()） - P 的数量稳定，M 的数量波动剧烈，G 的生命周期完全独立于两者
系统调用期间 G 不丢、M 和 P 解耦的关键机制
当一个 G 进入阻塞系统调用（比如 syscall.Read()），当前 M 会脱离 P，P 立即被其他空闲 M 获取继续执行别的 G。原 G 状态变为 Gsyscall，其栈和寄存器保存在 g->sched 中。系统调用返回后，原 M 尝试抢回 P；抢不到就将该 G 推入全局 runq，自己进入休眠。
立即学习“go语言免费学习笔记（深入）”；
- 这个过程不需要“某个 M 必须负责固定一批 G”，G 的归属由状态机 + 队列 +
allg链表管理 - 阻塞调用不导致整个 P 停摆，这是高并发吞吐的基础
- netpoll 机制让非阻塞 I/O 可以绕过系统调用，直接唤醒等待中的 G，进一步削弱对 M 数量的依赖
真正容易被忽略的点在于：P 是调度的稳定锚点，M 是执行的临时载体，G 是纯粹的任务单元——三者之间没有比例表、没有绑定表、没有控制器。所有“高效”“轻量”“高并发”的体验，都来自状态驱动的解耦设计，而不是靠维持某种映射比例。
