VSCode调试器不干预Go select分支选择，停在同case是因断点拖慢执行破坏竞争条件；真正决定分支的是运行时伪随机轮询，仅当多个case同时就绪时生效，default永远优先，调试时需控制channel就绪时机确保各case可被观察。
VSCode 调试器本身不“捕获” select 的随机分支逻辑——它只暂停执行、展示当前状态；真正决定哪个 case 被选中的是 Go 运行时的伪随机调度，调试器无法干预或预测，但可以帮你验证它是否按预期触发。
为什么断点打在 select 里，总停在同一个 case？
这不是 Go 的 bug，也不是 VSCode 的问题，而是调试行为改变了运行时环境：
-
select的“随机”仅在所有case都就绪（如 channel 有数据、timer 到期）时才生效；一旦某个case明显快于其他（比如default永远就绪），它就会被优先选中 - 加断点会显著拖慢执行节奏，导致原本竞争的 channel 操作变得“不同步”：前一个
case的发送/接收可能已先完成，后续case就永远等不到机会 - Delve 在暂停时会冻结 goroutine，而 channel 操作涉及 runtime 的调度器协作，暂停后部分状态（如 sendq / recvq）可能被固化，破坏了原始竞争条件
如何让 select 分支在调试中“可重现”又“可验证”？
目标不是让分支固定，而是确保每个 case 都有机会被观察到。关键在控制就绪时机：
- 避免在
select前直接写入无缓冲 channel：用go func() { ch 模拟并发写入，而不是同步写 - 对 timer 相关
case，改用time.After(time.Millisecond * 1)而非time.After(time.Nanosecond)，避免因调试延迟导致 timer 总是第一个就绪 - 在每个
case的第一行设断点（比如fmt.Println("hit default")），而不是打在select大括号上——这样能确认到底进了哪一分支 - 配合 DEBUG CONSOLE 手动检查 channel 状态：
print len(ch)或print cap(ch)，确认缓冲是否影响就绪判断
DEBUG CONSOLE 里怎么查 select 当前实际行为？
程序暂停在 select 内部（比如命中某个 case 的断点）后，在 DEBUG CONSOLE 中可做这些事：
-
goroutines：确认当前 goroutine 是否卡在select，State 显示chan receive或semacquire表示还在等 -
print <-ch：如果 channel 有值，这会立即返回；若阻塞，则说明该case未就绪（慎用，可能触发副作用） -
bt（backtrace）：看调用栈是否真停在你期望的case分支里，而非 runtime.selectgo 函数内部 - 不要依赖
print ch查 channel 内容——Go 的 channel 是 opaque 结构，直接打印只显示地址和容量
最常被忽略的点：你看到的“总是走 default”很可能是因为其他 case 的 channel 在调试暂停期间被清空或超时失效了，而不是代码逻辑有问题。验证前先关掉断点跑几轮，再用日志打点确认真实行为。
