安全，但仅限于接收端且channel已被发送方主动关闭；range会依次取出已入队元素后自动退出，不会panic或阻塞；发送方须是最后一个发送者，关闭后不可再发送，否则触发panic。
关闭 channel 后用 range 迭代是否安全？
安全，但仅限于「接收端」且 channel 已被明确关闭。Go 语言规范保证：range 在遍历已关闭的 channel 时，会依次取出所有已入队元素，然后自动退出循环——不会 panic，也不会阻塞。
关键前提是：channel 必须由**发送方（或唯一有写权限的一方）主动关闭**，且**不能在关闭后继续向其发送数据**，否则触发 panic: send on closed channel。
- 关闭前未读完的数据仍可被
range消费完 -
range内部隐式调用<-ch，每次成功接收一个值，直到 channel 关闭且缓冲区为空 - 若 channel 是无缓冲的，且发送方在关闭前未完成所有发送，
range仍能收完已发出的值（前提是发送已完成或 goroutine 已退出）
close() 谁来调用？常见误用场景
必须由「最后一个发送者」关闭 channel；接收方调用 close() 是错误的，Go 不禁止但语义错乱——它不表示“我不再读了”，而是“没人再往里写了”，而接收方本就不该负责这个职责。
典型误用：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 多个 goroutine 并发向同一 channel 发送，却由其中一个随意
close()→ 其他发送者可能仍在写，panic 随机出现 - 用
defer close(ch)在 goroutine 函数末尾，但该 goroutine 并非唯一发送者 - 把 channel 当作信号量，在接收端
close(ch)试图“通知结束” → 接收端无法可靠感知关闭时机，且违反协作契约
正确做法：用 sync.WaitGroup 或 context 控制发送侧生命周期，确保所有发送完成后再统一关闭。
如何判断 channel 是否已关闭？不用 range 时的接收惯用法
单独接收（非 range）时，靠多值接收语法判断：v, ok := 。当 <code>ok 为 false，说明 channel 已关闭且无剩余数据。
-
ok == false只表示「通道已关 + 缓冲为空」，不表示「刚被关闭」——可能早关了，只是你第一次读 - 若 channel 有缓冲，
ok仍为true直到缓冲耗尽 - 不要用
len(ch) == 0 && cap(ch) == 0判断是否关闭——len()和cap()对 channel 无效，编译不通过
示例：
for {
v, ok := <-ch
if !ok {
break // channel 已关闭且无数据
}
process(v)
}
为什么不能对 nil channel 做 range？
会永久阻塞，而不是 panic。因为 range nil_chan 等价于持续执行 <-nil_chan，而从 nil channel 接收永远阻塞（Go 规范定义）。
- 这和
close(nil_chan)不同——后者直接 panic - 常见陷阱：声明了 channel 变量但忘了
make()，比如var ch chan int，然后直接range ch - 调试时可用
if ch == nil提前 guard，尤其在函数参数校验中
真正容易被忽略的是：这种阻塞不会报错、不超时、不打印日志，只让 goroutine “静默卡死”，排查成本远高于 panic。
