select 是事件驱动的协作式状态机，需在 for 循环中配合 default 或超时避免阻塞；错误写法是无退出路径的无限 select，导致 goroutine 卡死或 cpu 空转。
goroutine 配合 select 实现多任务调度，核心不是“启动一堆 goroutine 然后靠 select 调度它们”，而是用 select 控制单个 goroutine 的行为分支——它本质是事件驱动的协作式状态机，不是操作系统级的抢占式调度器。
select 在 for 循环里怎么写才不卡死或狂占 CPU
常见错误是把 select 写在无休止的 for 里，又没加 default 或超时，结果 goroutine 永远阻塞在某个 channel 上，其他任务完全无法响应。
- 如果想轮询多个 channel 并及时响应新任务，必须把
select放在for内，但每个循环至少要有一个可退出路径 - 不要写
for { select { case —— 这等于把 goroutine 锁死在 <code>ch上，别的 channel 永远没机会被检查 - 真要轮询且不阻塞，用
default+ 短暂time.Sleep；但更推荐用带超时的select，比如case - 注意：
time.After每次调用都新建一个 timer，高频循环里建议复用time.NewTimer并在每次循环后Reset
nil channel 在 select 中的开关效果怎么用
nil channel 在 select 中永远不可读/不可写，不会 panic，但会让对应 case 彻底失效——这是 Go 官方支持的动态开关技巧，比布尔标志位更轻量、更并发安全。
- 初始化时设为
var ch chan int（即nil），这个case就不会参与调度 - 需要启用时，赋值为真实 channel：
ch = make(chan int, 1)，下次select就会监听它 - 禁用时再设回
nil，不用关 channel，也不用加锁判断状态 - 典型场景：任务调度器中按需开启/关闭某类任务输入源，或根据配置动态屏蔽健康检查通道
为什么用 select 处理多个 channel 比起轮询更高效
因为 select 是运行时直接挂起 goroutine，直到至少一个 channel 就绪；而轮询（比如 if len(ch) > 0）要反复检查、占用 CPU、还可能漏事件。
- channel 底层有等待队列，
select会把当前 goroutine 注册进这些队列，唤醒由 runtime 直接触发 - 轮询方式必须配合
time.Sleep，延迟和资源消耗不可控；select是零延迟响应（就绪即执行） - 多个
case同时就绪时，select随机选一个，避免饿死；轮询顺序固定，容易导致某 channel 长期独占 - 注意：
select每次只执行一个case，想处理所有就绪 channel，得自己用循环 +default+ 非阻塞操作（如select { case x := ）
goroutine 泄漏常出现在 select 的哪些写法里
最隐蔽的泄漏不是 goroutine 没结束，而是它被 select 卡住后永远等不到唤醒信号，比如 channel 关闭了但没通知，或 timer 没重置。
- 用
time.After做超时时，如果 goroutine 生命周期长于超时时间，timer 对象无法被 GC，累积造成内存增长 - 监听一个可能永久不关闭的 channel，又没配
default或超时，该 goroutine 就成了僵尸 - 在
select里接收ctx.Done()是好习惯，但忘了在case 后清理资源（如关闭子 channel、释放 buffer）也会泄漏 - 向已满的带缓冲 channel 发送数据，且没配超时或
default，select会一直阻塞在那个case，整个 goroutine 挂起
真正难调试的从来不是语法，而是你默认认为 select 会“公平轮转”或“自动重试”——它不会。它只做一次决策，之后全靠你设计循环逻辑和退出条件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
