Go语言嵌套通道场景下orDone函数执行逻辑疑问

首先明确Go语言通道关闭的核心特性，这是理解所有行为的基础：

对一个已关闭的通道执行读操作永远不会阻塞，会立刻返回通道对应类型的零值，同时返回的ok标志为false。关闭是通道的永久状态，不是一次性的消息事件，不存在“消费关闭信号”的说法。

逐个解答你的疑问 #

1. 内层select的case <-done会不会消费关闭信号？ #

不会。
通道关闭不是存在通道缓冲区里的特殊元素，不需要被读取消费。close(done)操作本质是修改了通道内部的关闭标记位，这个标记一旦设置就不会被清除。你在内层select中执行<-done触发分支，只是完成了一次普通的通道读操作，不会修改这个关闭标记——后续任何位置、任何次数读这个已关闭的done通道，都会立刻非阻塞返回。
这也是为什么内层select执行完done分支回到外层循环后，外层select的case <-done会立刻被命中，直接退出goroutine。

2. 通道关闭的信号是否会残留在通道中？ #

不存在“残留信号”的概念。
你可以把通道简化理解为一个带如下核心字段的结构体：

type hchan struct {
    // 其他字段：缓冲区、锁、读写等待队列等
    closed uint32 // 0代表未关闭，1代表已关闭
}

close(ch)操作的核心逻辑就是把closed字段设为1，之后所有对ch的读操作，都会先检查这个标记：如果是1，在缓冲区数据读完后，会直接返回零值+ok=false，不需要等任何写入，也不会从缓冲区取什么“关闭信号”。这个标记会一直存在直到通道被垃圾回收，不存在“读一次就消失”的情况。

3. 关闭通道时是否存在其他case被选中执行的可能？ #

存在，而且是符合Go select语义的正常行为。
Go的select语句在多个case同时就绪时，会随机公平选择一个case执行，没有固定优先级。
回到你的orDone代码场景：当你关闭done2时，如果刚好满足以下两个条件：

• 已经从源通道c读到了值v，走到了内层select逻辑
• 下游valStream的接收方（也就是你main函数里的range循环）正处于可接收状态
  那么内层select的两个分支valStream <- v和<-done会同时就绪，此时Go会随机选一个分支执行：
• 选中发送分支：就会把当前v发给下游，之后回到外层循环，再命中done分支退出
• 选中done分支：就会执行你写的打印逻辑，之后回到外层循环命中done分支退出
  你测试时观察到每次都进入内层done分支，只是测试场景下的时机巧合，不是必然结果。

补充说明 #

你看到的这个双层select结构，正是orDone模式的核心设计：

• 外层select同时监听done和源通道c，保证读源通道阻塞时可以及时响应取消
• 内层select同时监听done和valStream的发送操作，保证向下游发送值阻塞时（比如下游已经退出不接收了），也可以及时响应取消，不会出现goroutine泄漏

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