是，Goroutine 被标记为_Gwaiting并放入channel的sendq或recvq链表，不进入内核等待队列、不释放M、不触发系统调用，全程用户态纳秒级完成。
channel 阻塞时 Goroutine 真的“休眠”了吗？
不是挂起进操作系统等待队列，而是被调度器标记为 _Gwaiting 状态，并放入 channel 对应的 sendq 或 recvq（即所谓“休眠队列”）。这个队列是 Go 运行时维护的链表，不触发系统调用，也不释放 M，更不切换到内核态。
关键点在于：G 被移出 P 的本地运行队列后，P 可立即调度下一个 G；M 不会阻塞在 syscall 上（除非 channel 操作触发了底层 I/O，比如网络 read/write）；整个过程发生在用户态，耗时通常在纳秒级。
- 无缓冲 channel 阻塞：发送方 G 入
sendq，接收方 G 入recvq，双方都处于_Gwaiting，直到配对成功才被唤醒 - 有缓冲 channel 缓冲区满时发送阻塞：仅发送方入
sendq；缓冲区空时接收阻塞：仅接收方入recvq -
select语句中多个 channel 同时就绪时，Go 会伪随机选择一个分支，不会按书写顺序优先
GMP 中 channel 唤醒如何避免上下文切换开销？
唤醒不是靠轮询或信号，而是由 channel 操作的另一半直接“拉起”等待中的 G。例如：ch 执行时，若发现 <code>recvq 非空，就从队列头取出一个 G，将其状态设为 _Grunnable，并尝试推入当前 P 的本地运行队列（runq）或 runnext（高优先级插队位）。
这意味着：一次 channel 通信最多只涉及两次用户态调度决策（发端入队、收端出队），完全绕过 M 的系统级阻塞/唤醒路径。对比传统线程模型中 pthread_cond_signal + pthread_mutex_unlock 引发的至少一次内核态切换，这里省掉了全部 syscall 开销。
- 如果目标 P 正忙（比如正在执行其他 G），被唤醒的 G 会被暂存到全局队列（
global runqueue），由空闲 M 主动窃取 - 若唤醒时 P 没有绑定 M（比如刚被抢占），会触发
handoffp流程，快速将 P 与另一个空闲 M 关联 - 所有这些操作都在运行时内部完成，应用层无感知
为什么 close(ch) 后从 channel 接收不会 panic，但发送会？
因为关闭动作会原子地清空 sendq 并向其中所有 G 注入 panic（通过 goparkunlock 时检查 closed 标志），而 recvq 中的 G 则被批量唤醒，并统一返回对应类型的零值。这背后依赖 GMP 中对 G 状态和 channel 内部锁（lock 字段）的严格时序控制。
典型错误场景：close(ch) 和 ch 出现在不同 goroutine 且无同步，会导致竞态——运行时检测到向已关闭 channel 发送，立即触发 <code>panic: send on closed channel，这个 panic 发生在用户 goroutine 的栈上，不是调度器 panic。
- 从已关闭 channel 接收：返回零值 +
ok == false（仅限带 ok 形式v, ok := ） - 向已关闭 channel 发送：必定 panic，无法 recover（除非在 defer 中捕获，但此时 G 已处于不可恢复的终止状态）
- nil channel 的读写：永远阻塞，不会 panic，也不会唤醒，这是明确的未定义行为边界
GOMAXPROCS 设置不当如何放大 channel 切换延迟？
当 GOMAXPROCS 设得远小于 CPU 核心数（比如设为 1），所有 G 都挤在单个 P 上竞争运行队列；一旦某个 G 因 channel 阻塞被移出，唤醒时仍只能回到这唯一 P 的队列尾部，导致平均等待时间线性增长。实测中，万级 goroutine 在 GOMAXPROCS=1 下，channel 通信 p99 延迟可比 GOMAXPROCS=8 高 3–5 倍。
更隐蔽的问题是：P 数量不足会加剧全局队列争用。因为本地队列（runq）满后，新创建的 G 或被唤醒的 G 会被扔进全局队列，而全局队列访问需加锁；P 数越少，每个 P 窃取全局队列的频率越高，锁竞争越明显。
- 生产环境建议设为 CPU 核心数（
runtime.GOMAXPROCS(0)默认即如此） - 不要在运行时频繁调用
runtime.GOMAXPROCS(n)，每次调用会触发 STW（stop-the-world）片段，影响调度平滑性 - 若业务含大量 I/O 阻塞（如 HTTP 客户端调用），适当提高 P 数有助于隐藏 syscall 延迟，但超过物理核心数收益递减
真正容易被忽略的是：channel 的“休眠队列”本身不占堆内存，但每个等待中的 G 仍持有其栈（哪怕只有 2KB），而 G 对象本身（struct G）约 400 字节。当数十万 G 因 channel 阻塞堆积在 sendq/recvq 里，虽不触发系统调用，却实实在在吃着内存——这不是调度成本，而是资源持有成本。
