Golang内置函数close在通道（Channel）操作中的调用规范

在并发编程中，通道关闭是个看似简单实则容易出细节问题的操作。很多开发者都知道可以调用 close，但到底谁有资格调、调完会发生什么、接收方又该如何正确感知关闭状态——这些环节如果理解不透，很容易在运行时踩坑。

只有发送方能调用 close，且必须确保通道非 nil、未关闭；否则运行时 panic。

哪些通道类型允许调用 close

并非所有通道都具备被关闭的“资格”。严格来说，只有双向通道（chan T）和只写通道（chan<- T）可以调用 close。而只读通道（<-chan T）在编译期就会被拒绝，编译器会直接抛出 cannot close receive-only channel 的错误——换句话说，你连编译都过不了。

• make(chan int) 可 close
• make(chan<- int) 可 close
• make(<-chan int) 编译失败，无法调用 close
• 函数参数声明为 ch <-chan int 时，即便底层是双向通道，在该作用域内也无法调用 close

close 后继续发送会 panic，但接收仍安全

通道一旦关闭，任何继续向它发送数据的操作都会立即触发 panic: send on closed channel。而接收行为则相对宽容：已缓冲的数据仍然可以正常取出，取完之后返回零值加 false（多值接收）或直接返回零值（单值接收）。

• 假如有一个缓冲通道 ch := make(chan int, 2)，写入 2 个值后关闭它，后续 <-ch 仍能取出这两次数据，第三次开始返回 0, false。
• 无缓冲通道关闭后，如果此时没有发送方在等待，<-ch 会立即返回零值加 false。
• 需要注意的一种错误模式：go func() { for i := range data { ch <- i }; close(ch) }——range 本身不阻塞，但若 data 是无缓冲通道且无人接收，for range 会卡住，导致 close 永远无法执行。

重复关闭或关闭 nil 通道必然 panic

调用 close(nilChan) 或 close(alreadyClosedCh)，都会在运行时触发 panic，且无法 recover。这并非逻辑上的偶发错误，而是 Go 运行时层面的硬性检查。

• 常见误判：很多人会写 if ch != nil { close(ch) }，但这只能防住 nil 通道，无法防止重复关闭，需要额外状态控制。
• 在并发场景下，多个 goroutine 都可能走到 close 调用处，必须用 sync.Once 或原子布尔标志（如 atomic.CompareAndSwapUint32(&closed, 0, 1)）确保只执行一次。
• nil 通道通常出现在未初始化的字段或函数参数默认值中。比如 var ch chan int 直接传入并调用 close(ch)，就会触发 panic: close of nil channel。

接收方如何可靠感知关闭状态

接收方绝对不能靠“读到零值”来判断通道是否关闭——因为零值完全可能是合法数据。唯一可靠的方式是多值接收语法 v, ok := <-ch，其中 ok == false 才表示通道已关闭且没有剩余数据。

• for v := range ch 是最简洁的写法，它隐式使用 ok 判断，通道关闭后自动退出循环。
• 但需要注意：range 不会“中断”正在进行的接收过程；如果通道有缓冲，它会读完所有已存数据后才退出。
• 一种常见的错误模式：for { v := <-ch }——如果发送方已经 close，这个循环会无限接收零值，永远无法退出。
• 更健壮的显式写法是：for { if v, ok := <-ch; !ok { break } }。

说到底，真正容易出问题的往往不是语法记不住，而是谁关、何时关、对方怎么响应这三件事没对齐。举个例子：用 sync.WaitGroup 等待所有发送完成，却忘了在 Wait() 之后再执行 close；或者把 close 放在了 select 的 default 分支里，导致提前关闭。这些细节但凡漏掉一个，轻则数据丢失，重则死锁或 panic。