close()是单向关闭信号而非资源释放操作，仅最后一个可能写入channel的goroutine有权调用，误关、早关、多关均导致panic，接收方或多个发送方擅自关闭会引发运行时错误。
Go 里 close() 不是资源释放操作，而是单向信号：只告诉接收方“不会再有新数据了”。关错、早关、多关，八成 panic；不关，绝大多数情况也不会泄漏——别把它当 free() 用。
谁有资格调用 close()
只有明确知道自己是「最后一个可能往 channel 写数据」的 goroutine，才能关。编译器不检查逻辑，但运行时立刻报错：panic: close of closed channel 或更危险的 panic: send on closed channel。
- 接收方调用
close()：编译期就拦住——invalid operation: close(ch) (channel is receive-only) - 多个发送方各自判断“我写完了”就关：典型竞态，后关的那个必 panic
- 主 goroutine 启动 N 个 worker 往同一
chan int写，却没设终结者：没人该关，也没人敢关 - 函数参数是
ch 或 <code>ch chan？前者不能关，后者能关但得确认你真是唯一写入者
for range ch 退出的两个硬条件
for v := range ch 看似自动退出很省心，但它只在两个条件**同时满足**时才停：channel 已关闭 且 缓冲区中所有数据已被读完。漏掉任一，就会卡死或泄漏。
- 常见翻车：启动 goroutine 发送
ch ，紧接着 <code>close(ch)——若ch是无缓冲的，发送 goroutine 永远阻塞在，而 <code>range已退出，造成 goroutine 泄漏 - 有缓冲也不保险：若
cap(ch) == 10，你发了 8 个就close()，range能读完 8 个后退出；但若第 9 个还在发送途中，就可能 panic - 安全做法：用
sync.WaitGroup等所有发送 goroutine 显式 return 后，再close()；或改用select监听主动退出信号（如）
检测 channel 是否已关闭？别试了
Go 标准库没有线程安全、无副作用的函数能告诉你 channel 是否已关闭。网上流传的 select { case v := 技巧，本质是试探“此刻能否非阻塞接收”，它无法区分“channel 空了”和“channel 关了”。
v, ok := 中 <code>ok == false只在 channel 关闭 且 缓冲为空时才成立；若缓冲还有数据，ok仍为true，你读到的可能是合法零值（比如发了个0）- 用
len(ch)或cap(ch)判断？完全无效——它们只反映缓冲区状态，与关闭标志位无关 - 真正可靠的信号不是“channel 关了”，而是“我该停了”：用
context.Context控制生命周期，比依赖close()更正交、更可控
不关 channel，真的会泄漏或卡死吗？
绝大多数情况下，不调用 close() 不会导致泄漏或死锁。channel 本身是引用类型，当无 goroutine 持有它、也无人再读写时，会被 GC 回收。强行关闭反而是 bug 温床。
- 单次发送 + 单次接收，不用关也 OK（channel 自动被回收）
- 但凡用
for range ch遍历，又没关，程序卡死或 goroutine 泄漏 - 用
select带default的情况，不关也能跑，但语义上“数据流结束”无法传达 - 最麻烦的是多生产者场景：没人敢关，怕关早了；拖到最后关，又怕漏数据。这时候要么改用
sync.WaitGroup等齐所有发送完成，要么换context.Context控制生命周期——channel 本身不提供协作关闭机制
真正容易被忽略的一点：关闭 channel 不等于释放资源。它只是发了个“数据结束”信号；goroutine 是否退出、内存是否回收，全看你有没有同步机制配合。单靠 close()，解决不了任何竞态或泄漏问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
