通道关闭必须由发送端调用，因其本质是单向终止信号，语义为“数据发送完毕”，运行时强制禁止接收端关闭以避免 panic 和 goroutine 泄漏。
Go 语言中通道关闭不是“要不要关”的问题，而是“谁来关、何时关、怎么检测”三个动作必须对齐，否则极易引发 panic 或 goroutine 泄漏。
为什么 close(ch) 只能由发送端调用
通道关闭本质是单向终止信号，语义上代表“数据发送完毕”。Go 运行时强制要求只有发送方（即能写入 ch 或 chan）才能调用 <code>close()，接收方调用会编译失败或 panic。
- 双向通道
ch := make(chan int)和发送通道ch := make(chan 都可被关闭；但只读通道 <code> 无法关闭，传入 <code>close()会报错invalid operation: cannot close receive-only channel - 多个 goroutine 同时向同一通道发送？必须协调——通常用一个“发送协调者”统一关闭，而非每个发送者都尝试
close() - 重复关闭同一通道会触发 panic：
panic: close of closed channel，这点和 map 写入不同，没有“安全关闭”内置机制
接收端如何可靠判断通道已关闭
val, ok := 中的 <code>ok 不是“通道状态快照”，而是“本次接收是否成功取出有效值”。它在缓冲区为空且通道已关闭时才为 false；若缓冲区还有数据，即使通道已关，ok 仍为 true。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 错误用法：
if _, ok := —— 这只检测了单次接收，且可能因缓冲区未空而误判 - 正确模式：在循环中持续接收，直到
ok == false才退出，例如for v, ok := -
for range ch是更简洁的选择，它内部自动按相同逻辑处理，但仅适用于“接收全部剩余数据后退出”的场景；若需在中途响应关闭信号（比如清理资源），必须用多值接收
缓存通道关闭后还能读多少次
关闭后的通道行为取决于缓冲区是否清空：只要缓冲区还有数据， 就继续返回值且 <code>ok == true；只有缓冲区耗尽后，后续接收才返回零值 + ok == false。
- 示例：
ch := make(chan int, 2)，写入1、2后close(ch)，此时两次均返回对应值且 <code>ok == true；第三次才返回0, false - 这意味着不能靠“一次接收失败”就认定通道刚被关闭——它可能早就关了，只是你还没读完缓存
- 如果接收逻辑依赖精确的关闭时机（如触发 cleanup），不要依赖
ok，而应结合context或显式信号（如额外的 done channel）
常见泄漏与死锁陷阱
最隐蔽的问题不是 panic，而是 goroutine 永远阻塞在 或 <code>ch 上，且无外部干预手段。
- 发送端没关通道，接收端用
for range死等 → goroutine 泄漏 - 接收端提前退出，发送端还在往无缓冲通道写 → 发送 goroutine 永久阻塞
- 用
select等待多个通道时，没加default或context.Done()分支，导致无法响应关闭 → 卡死 - 忘记在 defer 中关闭通道（尤其在 error early return 场景），导致下游永远收不到关闭信号
真正难处理的从来不是“怎么关”，而是“关了之后，所有相关 goroutine 是否都能感知并退出”——这需要发送、接收、超时、取消四者协同，缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
