Go语言中何时使用终结器关闭Channel？

首先得明确这个设计的核心目的：防止接收方被意外丢弃时，发送方的goroutine永久阻塞导致资源泄漏。

你对终结器的理解是对的：当*Receiver[T]对象被GC判定为不可达（比如变量超出作用域、被置为nil且无其他引用）时，运行时会调用它的finalize方法，关闭done通道，通知发送方“接收方已经不在了，别再发数据了”。

为什么要靠GC兜底，而不是显式处理？ #

显式处理当然可行——比如给Receiver加一个Close方法，让使用者主动调用它来关闭done通道。但实际开发中，总会有使用者忘记调用显式关闭，或者因为代码路径复杂（比如发生panic、提前返回）导致无法执行关闭逻辑。这时候终结器就成了最后一道防线：即使没人管接收方，GC也会自动触发收尾操作，避免发送方的goroutine一直阻塞在Send调用里，最终造成goroutine泄漏。

举个实际场景 #

假设你写了一段代码：

s, r := Ranger[int]()
go func() {
    for i := 0; ; i++ {
        if !s.Send(i) {
            break // 收到结束信号，退出goroutine
        }
    }
}()

// 只接收3次数据就不再管r了
for i := 0; i < 3; i++ {
    fmt.Println(r.Next())
}
// 这里没有显式关闭r，r被丢弃

如果没有终结器，发送方的goroutine会一直卡在Send的select里（因为接收方已经不读values通道了，values <- i会一直阻塞），这个goroutine永远不会退出，直到程序结束。而有了终结器，当r被GC回收时，done通道被关闭，发送方的Send会返回false，goroutine就能正常退出。

总结 #

• 显式关闭是更主动、更可控的方式，但终结器是容错机制，用来覆盖开发者疏漏的场景。
• 这个设计的核心是平衡易用性和可靠性：既不用强制使用者必须记住关闭接收方，又能避免资源泄漏的问题。

内容的提问来源于stack exchange，提问作者joka