在Go并发编程中，因过早return导致channel阻塞，会引发goroutine泄漏。看似微小的逻辑疏忽，可能让系统在无声中耗尽资源。通过合理使用errgroup、缓冲channel或goleak检测，才能真正掌控并发的生命线。
一个看似简单却极易被忽视的问题——goroutine泄漏，尤其是因为过早返回return导致channel阻塞的经典陷阱。
这个问题听起来像是初学者才会犯的错，但实际上，连经验丰富的开发者也常常栽在这里。它不像空指针那样会立刻panic，也不像数据竞争那样会被race detector揪出来。它悄无声息地潜伏着，直到某天系统上线后内存缓慢爬升，监控报警不断，排查数小时才发现：几十个goroutine卡死在某个channel的发送操作上，再也醒不过来。
事情的起因往往很朴素：想并发执行几个任务，每个任务完成后通过一个无缓冲channel把结果传回来。主协程依次接收这些结果，一旦发现某个任务失败，就立刻返回错误，避免浪费资源继续等待。
逻辑听起来天衣无缝，但问题恰恰出在这个“立刻return返回”上。
比喻场景：你开了两个外卖小哥送餐，每人手里一份订单，约定好送到楼下就打电话给你。但你只愿意听第一个电话，如果一听是投诉就转身走人，根本不等第二个电话。这时候第二个小哥还在楼下举着手机拨号，风里雨里没人接，他只能一直站着，不能下班也不能接新单。这个小哥，就是被卡住的goroutine。
在Go里，无缓冲channel的发送操作是同步的，必须等到有人接收才会完成。如果你在接收之前就return了，那个正在尝试发送的goroutine就会永远卡在那条语句上。
它不会崩溃，不会报错，只是静静地挂着，像一根看不见的线，悄悄缠住系统的呼吸。
来看一个典型的错误写法：
go
type result struct{ err error }
func Example() error {
ch1 := make(chan result)
ch2 := make(chan result)
go func() { ch1 <- result{err: fmt.Errorf("oops")} }()
go func() { ch2 <- result{err: nil} }()
res1 := <-ch1
if res1.err != nil {
return res1.err // 错误：ch2的发送者将永远阻塞
}
res2 := <-ch2
if res2.err != nil {
return res2.err
}
return nil
}
这段代码的问题在于，当ch1返回错误时，程序直接返回，跳过了对ch2的接收；而第二个goroutine正在执行ch2 <- result{}，这个操作会一直阻塞，因为它是一个无缓冲channel，必须等到有人接收才能完成。
这个goroutine从此进入“僵尸状态”，再也无法被调度器回收。
一种简单的修复方式是确保所有channel都被读取，无论结果是否重要：
go
func ExampleDrain() error {
ch1 := make(chan result)
ch2 := make(chan result)
go func() { ch1 <- result{err: fmt.Errorf("oops")} }()
go func() { ch2 <- result{err: nil} }()
res1 := <-ch1
res2 := <-ch2 // 先接收，再判断
if res1.err != nil {
return res1.err
}
if res2.err != nil {
return res2.err
}
return nil
}
这种方式能避免泄漏，但代价是必须等待所有任务完成，哪怕其中一个已经失败。在某些高性能场景下，这种“全量等待”是不可接受的。
另一种思路是使用带缓冲的channel，让发送操作不会阻塞：
go
func ExampleBuffered() error {
ch1 := make(chan result, 1)
ch2 := make(chan result, 1)
go func() { ch1 <- result{err: fmt.Errorf("oops")} }()
go func() { ch2 <- result{err: nil} }()
res1 := <-ch1
if res1.err != nil {
return res1.err // 安全：ch2的值已进入缓冲区
}
res2 := <-ch2
if res2.err != nil {
return res2.err
}
return nil
}
缓冲channel解决了阻塞问题，但也带来了新的风险：你可能会彻底忽略未读取的channel。如果这些channel携带的是需要处理的状态或资源，问题依然存在。
真正优雅的解法是使用errgroup包，它把并发控制、错误聚合和上下文取消都封装好了：
go
import (
"golang.org/x/sync/errgroup"
)
func ExampleErrgroup() error {
var g errgroup.Group
g.Go(func() error {
return fmt.Errorf("oops")
})
g.Go(func() error {
return nil
})
return g.Wait()
}
更进一步，如果希望其他任务在某个任务失败时能及时退出，可以结合上下文：
go
import (
"context"
"time"
"golang.org/x/sync/errgroup"
)
func ExampleErrgroupWithContext() error {
g, ctx := errgroup.WithContext(context.Background())
g.Go(func() error {
return fmt.Errorf("oops")
})
g.Go(func() error {
for {
select {
case <-ctx.Done():
return ctx.Err()
default:
time.Sleep(10 * time.Millisecond)
}
}
})
return g.Wait()
}
这种模式下，一旦某个任务出错，上下文被取消，其他任务能通过ctx.Done()感知并主动退出，避免资源浪费。
最后，如何在开发阶段就发现这类问题？go vet和-race都无能为力，因为这不是语法错误或数据竞争。但可以使用Uber的goleak库，在测试结束时检查是否有goroutine未退出：
go
import "go.uber.org/goleak"
func TestBuggyLeaks(t *testing.T) {
defer goleak.VerifyNone(t)
_ = buggyEarlyReturn()
}
如果存在泄漏，测试会失败并打印出卡住的goroutine堆栈，帮助你快速定位问题。
Go的并发模型虽然简洁，但每一个channel、每一个goroutine背后都有其运行时契约。理解这些契约，才能写出真正健壮的代码。