本文解析 Go 程序中因嵌套循环导致 channel 接收永久阻塞的典型错误，通过重构 for scanner.Scan() 的控制结构、合理使用 select 和通道关闭机制，确保流处理及时终止并避免 goroutine 挂起。

本文解析 go 程序中因嵌套循环导致 channel 接收永久阻塞的典型错误，通过重构 `for scanner.scan()` 的控制结构、合理使用 `select` 和通道关闭机制，确保流处理及时终止并避免 goroutine 挂起。

在 Go 并发编程中，使用无缓冲或带缓冲 channel 进行生产者-消费者模式时，若控制逻辑存在结构性缺陷，极易引发接收端永久阻塞（如本例中 line5 后卡死）。根本原因在于：原代码将 for scanner.Scan() 嵌套在无限 for { } 循环内，导致即使 scanner.Scan() 返回 false（扫描结束），外层循环仍持续执行，进而使 select 中的 default 分支反复尝试向已满或即将关闭的 stream 发送数据——而更关键的是，当 donec 关闭后，break escape1 仅跳出外层循环，但 scanner.Scan() 已不再返回新值，goroutine 却未退出，close(exitc) 被延迟执行，最终造成主 goroutine 在

✅ 正确写法：扁平化扫描循环，精准控制退出时机

应直接将 scanner.Scan() 作为 for 条件，而非嵌套于无限循环中。这样可确保扫描自然结束后立即执行清理逻辑：

使用Go语言搭建家庭相册系统-相关课件

使用Go语言搭建家庭相册系统-相关课件

下载

func main() {
    var (
        donec  = make(chan struct{})
        stream = make(chan string, 5000) // 缓冲足够容纳所有行
        exitc  = make(chan struct{})
    )

    go func() {
        scanner := bufio.NewScanner(strings.NewReader(lines))
    escape1:
        for scanner.Scan() { // ✅ 关键：Scan() 作循环条件，避免空转
            select {
            case <h3>⚠️ 注意事项与最佳实践</h3>

• 避免冗余循环：bufio.Scanner.Scan() 本身已封装 EOF 判断，重复包裹 for { for scanner.Scan() { ... } } 会导致逻辑失控；
• 通道关闭需谨慎：close(stream) 应在确认不再发送后调用；消费者通过 ok 值检测关闭状态（如示例中 if !ok 分支）；
• 同步等待要配对：
• 缓冲容量要合理：本例设为 5000 可暂存全部输入，若数据量动态不可控，建议改用无缓冲 channel + 超时控制，或结合 context 实现优雅中断。

修复后的程序将严格按预期输出：

line1
line2
line3
line4
line5
escape1
scan done
done....

这不仅是语法修正，更是对 Go 并发模型中「循环控制权归属」和「通道生命周期管理」的深刻实践。