从已关闭channel接收时，ok为false且val为t类型零值，并非错误；go规定此举不panic也不返回error，唯一可靠判断通道关闭的方式是检查ok。
select中从已关闭channel接收时，ok为false但val是零值，不是错误
很多人误以为从已关闭channel读取会panic或返回error，其实不会。Go语言规定：从已关闭的chan T接收，立即返回T类型的零值（如0、""、nil），同时ok为false。这个ok才是判断通道是否关闭的唯一可靠依据。
- 写法必须是
val, ok := ，不能只写<code>val := ，否则无法区分“收到零值”和“通道已关” - 如果
T是int，而业务中合法数据包含0，仅靠val == 0判断关闭会出错 - 关闭后继续向channel发送数据才会panic，接收永远安全
多个channel共用一个select循环时，如何安全退出
常见错误是只检查单个ok就break，结果其他channel还在发数据，导致goroutine泄漏或死锁。真正安全的退出需要跟踪每个channel的状态，并在全部关闭后才终止循环。
- 为每个channel配一个布尔变量（如
ch1Closed、ch2Closed），在ok == false时设为true - 每次case执行完，检查所有关闭标志是否全为
true，是则break外层循环 - 不要在
default分支里做退出判断——它不等待，可能在数据还没来时就跳过接收 - 若使用
for range ch替代select，它会自动在channel关闭后退出，但只能用于单个channel
带default的select在关闭检测中容易引发忙等
加default本意是避免阻塞，但在多channel消费场景下，它会让循环变成高频轮询，CPU飙升，且无法及时响应真正的关闭信号。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
default分支执行时不等待任何channel，只要没case就绪，立刻跑一遍default - 若
default里放了状态检查逻辑（比如轮询ch1Closed && ch2Closed），看似能退出，实则浪费资源 - 正确做法是去掉
default，让select阻塞等待——只要还有channel开着，就该等；只有全部关闭才该退出 - 如果必须非阻塞（如UI响应），改用
time.After(1 * time.Millisecond)代替default，控制轮询节奏
关闭channel的职责必须明确，否则ok不可信
ok为false只说明“发送方已调用close()”，但如果关闭时机不对，消费者看到的仍是脏数据或竞态结果。
- 必须由**唯一的发送方**负责关闭，多个goroutine并发close会panic
- 发送方应在**所有发送操作完成后**再close，不能一边发一边关
- 若用
sync.Once包装close，要确保Once对象作用域覆盖所有可能的关闭路径 - 接收方不能假设“收到
ok==false就代表所有数据已送达”——需配合业务逻辑确认（例如发送方先发结束标记再close）
实际并发鲁棒性不取决于语法多炫，而在于对ok语义的敬畏、对关闭责任的厘清、以及对阻塞/非阻塞意图的诚实表达。这些地方写错一行，调试起来就是数小时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
