个人理解哈。先说结论：golang 的 channel 不应该直接对 channel 本身判断是否 close 了。
以前我分享过一个文章，叫做：Go 为什么没有判断 close 的接口？
Go 为什么没有判断 close 的接口？
相信大家初学 golang chan 的时候应该都遇到过 "send on closed channel" 的 panic 。这个 panic 是当你意图往一个已经 close 的 channel 里面投递元素的时候触发。那么你当你第一次遇到这个问题是否想过 channel 是否能提供一个接口方法来判断是否已经 close 了？我想过这个问题，但是把 chan 的源代码翻了个遍没有找到。为什么？
我先 hold 这个问题，我们捋一下跟 channel close 相关的事情，主要思考到 3 个问题：
首先，用户可以 close channel，如下：
用 gdb 或者 delve 调试下就能发现 close 一个 channel，编译器会转换成 closechan 函数，在这个函数里是关闭 channel 的全部实现了，我们可以分析下。
对应编译函数为 closechan ，该函数很简单，大概做 3 个事情：
通过上面的代码逻辑，我们窥视到两个重要的信息：
但是很奇怪的是，我们 golang 官方没有提供一个接口用于判断 chan 是否关闭？那我们能不能实现一个判断 chan 是否 close 的方法呢？
怎么实现？首先 isChanClose 函数有几点要求：
回忆下 golang channel 最详细剖析 章节，想想 send, recv 相关的函数，我们可以知道，当前 channel 给到用户的使用姿势本质上只有两种：读和写，我们实现的 isChanClose 也只能在这个基础上做。
“写”肯定不能作为判断，总不能为了判断 chan 是否 close，我尝试往里面写数据吧？这个会导致 chansend 里面直接 panic 的，如下：
当然了，你路子要是野一点，这样做技术上也能实现，因为 panic 是可以捕捉的，只不过这也太野了吧，不推荐。
“读”来判断。分析函数 chanrecv 可以知道，当尝试从一个已经 close 的 chan 读数据的时候，返回 （selected=true, received=false），我们通过 received = false 即可知道 channel 是否 close 。chanrecv 有如下代码：
所以，我们现在知道了，可以通过 “读”的效果来判断，但是我们不能直接写成这样：
上面是个错误示例，因为 _, ok := <-c 编译出来的是 chanrecv2 ，这个函数 block 赋值 true 传入的，所以当 c 是正常的时候，这里是阻塞的，所以这个不能用来作为一个正常的函数调用，因为会卡死协程，怎么解决这个问题？用 select 和 <-chan 来结合可以解决这个问题，select 和 <-chan 结合起来是对应 selectnbrecv 和 selectnbrecv2 这两个函数，这两个函数是非阻塞的（block = false ）。
正确示例：
网上很多人举了一个 isChanClose 错误的例子，错误示例：
思考下：为什么第一个例子是对的，第二个例子是错的？
因为，第一个例子编译出来对应的函数是 selectnbrecv2 ，第二个例子编译出来对应的是 selectnbrecv1 ，这两个函数的区别在于 selectnbrecv2 多了一个返回参数 received，只有这个函数才能指明是否元素出队成功，而 selected 只是判断是否要进到 select case 分支。我们通过 received 这个返回值（其实是一个入参，只不过是指针类型，函数内可修改）来反向推断 chan 是否 close 了。
小结：
其实这些原则只有一点：一定要是安全的是否才能去 close channel 。
上面实现的 isChanClose 是可以判断出 channel 是否 close，但是适用场景优先，因为可能等你 isChanClose 判断的时候返回值 false，你以为 channel 还是正常的，但是下一刻 channel 被关闭了，这个时候往里面“写”数据就又会 panic ，如下：
因为判断之后还是有时间窗，所以 isChanClose 的适用还是有限，那么是否有更好的办法？
我们换一个思路，你其实并不是一定要判断 channel 是否 close，真正的目的是：安全的使用 channel，避免使用到已经关闭的 closed channel，从而导致 panic 。
这个问题的本质上是保证一个事件的时序，官方推荐通过 context 来配合使用，我们可以通过一个 ctx 变量来指明 close 事件，而不是直接去判断 channel 的一个状态。举个栗子：
ctx.Done() 事件发生之后，我们就明确不去读 channel 的数据。
或者
ctx.Done() 事件发生之后，我们就明确不写数据到 channel ，或者不从 channel 里读数据，那么保证这个时序即可。就一定不会有问题。
我们只需要确保一点：
关闭一个 channel 直接调用 close 即可，但是关闭一个已经关闭的 channel 会导致 panic，怎么办？panic-recover 配合使用即可。
这并不优雅。
可以使用 sync.Once 来确保 close 只执行一次。
这看着还可以。
对于关闭 channel 这个我们有两个简要的原则：
可以使用 sync.WaitGroup 来同步这个关闭事件，遵守以上的原则，举几个例子：
第一个例子：一个 sender
这里例子里面，我们在 sender 的 goroutine 关闭 channel，因为只有一个 sender，所以关闭自然是安全的。receiver 使用 WaitGroup 来同步事件，receiver 的 for 循环只有在 channel close 之后才会退出，主协程的 wg.Wait() 语句只有所有的 receivers 都完成才会返回。所以，事件的顺序是：
一切都是安全的。
第二个例子：多个 sender
这个例子我们看到有多个 sender 和 receiver ，这种情况我们还是要保证一点：close(ch) 操作的只能有一个人，我们单独抽出来一个 goroutine 来做这个事情，并且使用 context 来做事件同步，事件发生顺序是：
一切都是安全的。
文章链接：
希望对你有所帮助，谢谢。
