Go 关闭带缓冲 channel 后为什么还能读完剩余元素

会读完，是因为 close(ch) 关闭的是“继续发送”的入口，不是把缓冲区清空。只要关闭前已经成功写入了元素，接收方仍能按先入先出的顺序把这些元素取出；等缓冲区也空了，下一次接收才会拿到元素类型的零值，并且 ok 为 false。

关闭只禁止继续发送，不会抹掉缓冲区

下面的 channel 容量是 3，发送方先写入三个整数，再关闭 channel。关闭动作只改变 channel 的状态：后续发送会被禁止，但缓冲区里的 10、20、30 仍然存在。

package main

import "fmt"

func main() {
	ch := make(chan int, 3) // 创建容量为 3 的缓冲 channel
	ch 

这段代码的输出仍是 10、20、30。可以把 channel 的状态拆成两件事看：一是“还允不允许发送”，二是“缓冲区是否还有待接收数据”。前者已经关闭，不代表后者立刻为空。

用 ok 和 range 区分剩余元素与结束信号

如果接收逻辑需要知道 channel 是否关闭，就不要只判断 value == 0。因为 0 可能本来就是生产者发送的有效数据，双返回值才是可靠边界。

for {
	value, ok := 

只想把所有数据消费完时，for value := range ch 更简洁。它等价于持续接收并检查关闭状态：缓冲区里的元素先被交付，关闭且没有剩余元素后循环结束。若只写 value := ，则无法从返回值中区分“关闭后的零值”和“发送来的零值”。

生产代码里最容易踩的三个关闭边界

• 不要向已关闭 channel 发送。发送会触发 panic，关闭方应当确保没有后续发送者。
• 不要重复 close。同一个 channel 第二次关闭同样会 panic；关闭责任通常交给明确的发送方。
• 不要用零值判断结束。用 ok 或 range 判断，否则合法的 0、空字符串或 nil 指针都可能被误判。

多生产者场景尤其要先协调发送结束，再由一个明确的协调者关闭 channel。接收方通常只负责消费，不要在还可能有发送的情况下抢先关闭。

常见问题

关闭后还能接收多久？

直到关闭前已经写入缓冲区的元素全部被取走。缓冲区为空后，接收返回零值和 ok=false。

无缓冲 channel 关闭后也能读到数据吗？

如果关闭前已经有一次发送与接收完成，就不存在待排队元素；关闭后的接收会直接得到零值和 ok=false。带缓冲 channel 的“读完剩余元素”来自关闭时已经存在的缓存数据。

能不能用 len(ch) 判断是否读完？

不建议把 len(ch) 当作结束信号。并发发送和接收会让长度变化，关闭状态应使用 ok 或 range 表达。

参考：Go 语言规范：Channel types。