VSCode调试器不自动识别select阻塞状态，仅显示停在select语句行，无法标出具体等待的channel；是否真阻塞需人工判断default存在、channel是否nil及就绪情况。
VSCode 调试器本身不感知 select 的阻塞状态，你看到的“卡住”，其实是 goroutine 停在了 select 语句上，而它是否真在阻塞，取决于是否有 default、通道是否为 nil、以及各 channel 是否就绪——这些都得靠人工判断，不是调试器自动标出来的。
为什么断点停在 select 上，但看不到“正在等哪个 channel”
Delve（VSCode 背后的调试器）只记录 goroutine 当前指令位置，不解析 select 内部调度逻辑。它不会告诉你“现在正等待 c1 可读”，只会显示 PC 指向 select 开头那行。
-
select是 Go 运行时的复合调度操作，编译后没有单条对应机器指令，Delve 无法拆解其内部就绪判断过程 - 即使所有
case都不可执行，只要存在default，goroutine 就不会真正阻塞——但 VSCode 界面看不出这点，它只显示“停在这行”，容易误判为卡死 - 若某个
case对应的是nilchannel（比如case 中 <code>ch == nil），该分支永远不可就绪，但调试器也不会高亮或提示这个事实
如何确认 select 是否真在阻塞（而不是立刻走 default）
必须结合代码逻辑 + 调试控制台手动验证，不能只看暂停位置。
- 在 DEBUG CONSOLE 中输入
goroutines，找到当前 goroutine ID（比如17），再输入goroutine 17 bt查看完整堆栈：如果最后一帧是runtime.selectgo，说明它确实在等待——但没default或所有非-nil channel 都未就绪 - 检查
select块里有没有default分支：有 → 必然不阻塞；无 → 才可能阻塞 - 逐个 inspect 每个 channel 变量：
ch1、ch2是否为nil？缓冲区是否满/空？发送方是否已启动且未 panic？ - 特别注意超时 channel：
time.After(3 * time.Second)在调试时可能因暂停被跳过，导致case 永远不就绪——这不是 bug，是调试器干扰了时间语义
nil channel 在 select 中的“静默失效”怎么验证
nil channel 的 case 不会报错、不会警告、也不会出现在就绪列表里，它只是被运行时彻底忽略。这是设计行为，但调试时极易漏掉。
- 在 DEBUG CONSOLE 中对 channel 变量求值，如
ch，若输出为<nil></nil>，则对应case已失效 - 不要写
if ch != nil { select { ... } }来规避——这破坏了select的原子性，反而引入竞态 - 想临时启用/禁用某路，就直接赋值/置
nil，然后靠select自动过滤，这是最安全的做法 - 对
nilchannel 执行close(ch)会 panic，但 panic 不会在select内部发生，只会在你显式调用时触发
真正难的不是“看到阻塞”，而是区分“假阻塞”（有 default 却没意识到）、“伪就绪”（nil channel 让你以为少了一路）、以及“时间失真”（time.After 在调试中失效）。这些都得靠读代码 + 控制台命令交叉验证，VSCode 的 UI 层不提供任何捷径。
