Go语言子Goroutine无法接收父Goroutine通道消息的问题排查求助

我一眼就看到问题出在你的Worker Goroutine的循环逻辑上——你用了带default分支的select，再加上阻塞的stream.Read调用，直接导致Worker根本没机会去监听loglistenmgm通道的停止信号！

问题根源拆解 #

1. 当select语句包含default分支时，只要<-loglistenmgm这个case没有就绪（通道内无消息），代码会立刻进入default分支执行stream.Read(buf)。
2. 如果日志流暂时没有新消息，stream.Read会完全阻塞整个Worker Goroutine，它连回到select循环的机会都没有，更别说处理你发送的停止信号了。哪怕你往loglistenmgm通道发送了消息，Worker也卡在Read调用里无法响应。
3. 你提到移除loglistenmgm缓冲区后，发送操作会永久阻塞，这也验证了这个判断：所有Worker都卡在阻塞的Read操作中，没有Goroutine在监听loglistenmgm通道，导致发送方无法完成写入。

修复方案 #

我们需要把阻塞的日志读取操作从Worker的主循环中抽离，放到单独的子Goroutine里，用通道传递读取结果，让主Goroutine专注于监听停止信号、日志数据和错误。修改后的Worker代码如下：

func getOnePodLogs(logStream chan string, errorStream chan error, loglistenmgm chan bool, done chan bool, pod string) {
    stream, err := podLogRequest.Stream()
    if err != nil {
        log.Error(err.Error())
        errorStream <- err
        return
    }
    defer stream.Close()

    // 启动子Goroutine专门处理日志流读取，避免阻塞主循环
    dataChan := make(chan []byte)
    errChan := make(chan error)
    go func() {
        defer close(dataChan)
        defer close(errChan)
        buf := make([]byte, 1000)
        for {
            numBytes, err := stream.Read(buf)
            if numBytes > 0 {
                // 必须复制buf内容，否则下一次Read会覆盖当前数据
                copiedBuf := make([]byte, numBytes)
                copy(copiedBuf, buf[:numBytes])
                dataChan <- copiedBuf
            }
            if err != nil {
                if err != io.EOF {
                    errChan <- err
                }
                return
            }
        }
    }()

    // 主循环专注监听停止信号、日志数据和错误
    for {
        select {
        case <-loglistenmgm:
            log.Info(pod + " stop listening to logs")
            return
        case data := <-dataChan:
            logStream <- string(data)
        case err := <-errChan:
            log.Error("Error getting stream.Read(buf)")
            log.Error(err)
            errorStream <- err
            return
        }
    }
}

额外注意事项 #

你的Handler中done通道是带缓冲的，但当某个Worker正常读完日志流并发送done <- true时，Handler的Stream函数会立刻收到并返回，导致其他Worker还没收到停止信号就被遗弃。这是一个潜在的逻辑漏洞，后续可以考虑用sync.WaitGroup来等待所有Worker完成，或者调整done通道的处理逻辑。

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