for-range读取channel时程序卡住是因为它会持续阻塞等待channel关闭；必须确保有且仅有一个goroutine调用close(ch)，否则panic；动态sender场景下“发完即关”不可靠，可用value, ok := <-ch检测关闭状态。
for-range 读取 channel 时，为什么程序卡住不退出？
因为 for range 会一直等待 channel 关闭才结束循环；只要没人关它，哪怕里面没数据了，也会永久阻塞在 range 的那条语句上。
常见错误现象：goroutine 持续运行、CPU 占用低但程序不结束、日志停在某一行不再输出。
- 只用
for range ch前，必须确保有且仅有一个 goroutine 调用close(ch) - 不能在多个 goroutine 里并发调用
close(ch)，否则 panic：panic: close of closed channel - 如果 sender 是动态生成的（比如从 HTTP 请求流式写入），别依赖“发完就关”——网络延迟或 panic 可能导致关闭被跳过
如何安全检测 channel 是否已关闭，而不依赖 range？
用 value, ok := 手动判断。这是唯一能实时感知关闭状态的方式，<code>for range 内部其实也是这么做的，但它把逻辑封装掉了。
使用场景：需要在读不到数据时做其他事（比如超时重试、切换 source、记录统计），而不是干等关闭。
立即学习“go语言免费学习笔记（深入）”；
-
ok为false表示 channel 已关闭且无剩余数据 - 如果 channel 还开着但暂时没数据，
ok仍为true，只是阻塞等待 - 搭配
select使用更灵活，比如加default非阻塞尝试，或加timeout防卡死
select {
case v, ok := <-ch:
if !ok {
fmt.Println("channel closed")
return
}
handle(v)
case <-time.After(5 * time.Second):
fmt.Println("timeout")
}range channel 和 for {} + select {} 的性能与语义差异
for range ch 语义简洁，但它是“被动等待关闭”的单向消费模型；for {} select{} 更底层，可主动控制生命周期，也更容易嵌入复杂逻辑。
性能影响很小，差别主要在可维护性：前者适合“管道终点”，后者适合“中继节点”或带状态的消费者。
-
for range编译后实际展开为带recv检查的循环，和手动recv几乎一样快 - 但
for range无法在读取中途 break 后再 resume —— 它一旦退出，后续再 range 同个 channel 会立即返回（因已关闭） - 如果 consumer 需要“暂停/恢复”或“按条件跳过某些值”，必须用
select+ 手动 recv
自动关闭 channel 的常见误判：什么情况下你以为它关了，其实没关？
最典型的陷阱是：sender goroutine panic 了，或者被 runtime 杀掉（如父 context cancel），导致 close(ch) 根本没执行。
另一个是 sender 和 receiver 生命周期不对齐——比如 sender 在 main 退出前就结束了，但 main 没等它，也没 close。
- 别靠“sender 逻辑走完了”推断 channel 已关；要用显式
close()或同步机制（如sync.WaitGroup）保证顺序 - 用
defer close(ch)要小心：如果函数提前 return，defer 不会触发；建议 close 放在 sender 最后一行，或用 defer 包裹整个 sender 函数 - 测试时别只测 happy path；加 goroutine crash、context timeout 等 case，观察 channel 是否真的被关
真正难的不是语法，是怎么让关闭这件事，在并发、异常、超时混杂的现实里，依然可预期、可验证。
