G 不绑定 M，因其是用户态协程，仅运行时临时借用空闲 M，阻塞或抢占后立即让出 M 并入队等待；M 必须绑定 P 才能执行 G，调度路径为 G→P→M，而非 G→M。
M 和 G 之间没有直接绑定关系，G 只在运行时临时“借”M 执行，且随时可被切换到另一个 M —— 这是 Go 调度器实现高并发和轻量级协程的核心前提。
为什么说 G 不绑定 M？
Go 的 G（goroutine）本质是用户态协程，不依赖固定线程。它只在被调度执行时，才被某个空闲的 M 拿去跑；一旦 G 阻塞（比如系统调用、channel 等待）、或被抢占（如超过 10ms），就会立即让出 M，该 M 可能立刻去执行别的 G，而原 G 会被放回队列，等待下一次被任意一个可用的 M 拿走。
-
G的栈是堆上分配的、可增长的，与M的内核栈完全分离 -
M的结构体里没有字段存G列表，只有当前正在运行的g（即m.curg）和调度栈g0 - 调试时用
runtime.Stack查G的调用栈，不会显示它“属于”哪个M，因为这个关系是瞬时的
M 必须绑定 P 才能执行 G，但 P 可以换 M
M 不能直接执行 G，必须先获得一个 P（processor）。而 P 是资源上下文载体：本地队列、内存分配器、定时器轮询器等都绑定在 P 上。所以调度路径是：G → P → M，不是 G → M。
- 当
M因系统调用阻塞时，会主动释放持有的P，其他空闲M可立即抢走该P并继续执行其队列里的G - 一个
P在任意时刻最多被一个M持有；但一个M在生命周期中可能先后绑定多个P（例如启动时、P 被抢占后重新获取） - 若所有
P都被占用，新创建的G会进全局队列；而新唤醒的M会优先从全局队列或偷窃其他P的本地队列拿G
常见误判场景：看到 runtime.gopark 就以为 G 锁死了 M
很多开发者看到 goroutine 在 runtime.gopark 状态，就认为它占着某个 M 不放 —— 实际上这恰恰说明它已主动让出了 M。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
gopark是G主动挂起自己、进入等待状态，并把控制权交还给调度器；此时M已脱离该G，可立刻执行下一个任务 - 真正会“卡住”
M的是未被封装的阻塞系统调用（如read直接调用 libc，且未启用netpoll），这时M会脱离P进入休眠，直到系统调用返回 - 可通过
go tool trace观察G的状态迁移（Runnable → Running → Syscall → Runnable），确认是否真有M被长期独占
什么时候你会意外发现 G 和 M 的“强关联”？
仅在极少数底层调试或 runtime 交互场景中，才会显式暴露这种瞬时绑定：
-
runtime.LockOSThread()会让当前G和当前M强制绑定，禁止调度器切换；用于需要 OS 线程局部性的场景（如 CGO、TLS 设置） - 使用
debug.SetMaxThreads限制M数量后，若大量G同时陷入系统调用，可能导致M耗尽、新G无法及时调度 —— 这不是绑定问题，而是资源竞争 -
pprof中的 goroutine stack trace 显示的MID（如m=0x7f8b...）只是采样时刻的快照，不代表长期归属
真正需要关注的不是 “G 属于哪个 M”，而是 “G 是否能及时获得 P 和 M 的组合来执行”。P 的数量（GOMAXPROCS）、全局/本地队列的负载均衡、以及系统调用是否被正确封装，才是影响调度效率的关键变量。
