Go goroutine 为什么因无人接收而泄漏

如果一个 goroutine 把结果发送到无人接收的无缓冲 channel，它不会“自动结束”，而是停在发送表达式上。最常见的触发方式是：父 goroutine 遇到错误提前返回，接收循环随之结束，剩余 worker 仍执行 ch ，于是它们一直占着栈和引用。修复重点不是盲目增加 goroutine，而是给发送方一条明确的完成、取消或有界缓冲路径。

只要一个goroutine的阻塞逻辑没有外部触发退出的条件，运行时就会一直保留它的执行上下文，哪怕主协程后续执行完退出前都没法回收这类被卡住的协程，这就是无人接收时协程泄漏的核心成因。

先看一个“没人收结果”的最小现场

下面的代码把一个结果通道交给多个 worker。只要其中一个 worker 返回错误，父函数就提前结束接收循环；其他 worker 仍会尝试发送结果。由于 make(chan result) 创建的是无缓冲 channel，发送必须等到对应接收方出现。

package main

import "fmt"

type result struct {
    value int
    err   error
}

func process(items []int) ([]int, error) {
    ch := make(chan result)
    for _, item := range items {
        item := item
        go func() {
            // worker 完成后把结果交给父 goroutine；这里没有取消出口。
            ch 

这段最小例子没有错误分支，但它展示了关键契约：接收次数必须覆盖所有发送次数。真实项目里错误通常来自某个 worker 或下游依赖，父函数一旦提前 return，其余发送点就失去接收者。图1把父函数、结果通道和 worker 的静态关系画出来，重点看“接收循环退出”与“发送点仍存在”的边界。

为什么“无人接收”会变成泄漏

Go 语言规范规定，容量为零的 channel 只有发送方和接收方同时准备好时通信才成功；缓冲 channel 也只是在缓冲区未满时允许发送。发送方阻塞本身并不等于泄漏，只有当未来已经不存在能让它继续的接收或取消条件时，阻塞才会永久化。

因此，单纯把 channel 改成更大的缓冲并不能证明问题消失。如果 worker 数量超过容量、错误路径提前结束，或者 channel 实际上是 nil，发送照样没有终点。排查时应先问“谁负责接收、它在哪些分支会退出、发送方是否能感知退出”，再决定是否需要缓冲。

让发送方拥有可退出的取消路径

更稳妥的修复是让每个发送都同时监听取消信号。父函数返回错误前调用 cancel，已经完成工作的 worker 可以正常交付，尚未交付的 worker 则从 ctx.Done() 分支退出。这里的重点是：取消必须进入发送点，而不是只在父函数里声明一个 context。

func processWithCancel(parent context.Context, items []int) ([]int, error) {
    ctx, cancel := context.WithCancel(parent)
    defer cancel() // 正常返回和错误返回都释放未完成 worker。

    ch := make(chan result)
    for _, item := range items {
        item := item
        go func() {
            r := result{value: item * 2}
            select {
            case ch 

示例省略了 worker 内部的真实错误来源，但保留了必须存在的控制关系：发送和接收都能观察取消。若结果允许丢弃，也可以使用容量与 worker 数量匹配的结果 channel 作为兜底；不过这只解决“结果暂存”问题，无法替代对网络、数据库或其他阻塞操作的取消设计。

用阻塞栈确认泄漏位置

遇到 goroutine 数量持续上涨时，先看阻塞栈是否集中在同一个发送表达式。Go 1.27 的 runtime/pprof 提供了 goroutineleak profile；如果环境或版本不提供该 profile，也可以查看常规 goroutine profile 和阻塞栈。下面是接入 HTTP pprof 的最小片段：

import (
    _ "net/http/pprof"
    "net/http"
)

func startProfileServer() error {
    // 仅示意把标准 pprof 处理器挂到本地调试端口。
    return http.ListenAndServe("127.0.0.1:6060", nil)
}

观察结果时不要只看 goroutine 总数。若大量栈停在 ch ，同时父函数已经走了错误返回，基本可以确认接收生命周期与发送生命周期脱节。修复后再关注同一调用路径的阻塞栈是否回落，并检查取消分支是否真的覆盖所有发送点。

• 发送 channel 是否可能为 nil，是否在所有路径上初始化？
• 父函数提前返回、超时或关闭时，worker 是否能收到取消信号？
• 缓冲容量是否只是经验数字，还是与可接受的未消费结果数量相匹配？
• worker 内部的网络、文件或锁等待，是否也有独立的退出条件？

常见问题

给 channel 加一个缓冲就一定不泄漏吗？

不一定。缓冲只提供有限的暂存空间；写满后发送仍会阻塞，且 worker 可能在发送前就卡在其他资源上。它适合明确的有界结果场景，不能代替取消协议。

关闭 channel 能解决发送方泄漏吗？

关闭只改变接收方看到的状态，不能让已经阻塞的发送变成成功发送；错误地在仍有发送者时关闭还会触发 panic。应先设计发送者退出和所有权，再决定谁负责关闭。

为什么 goroutine 没有报错却一直占用内存？

阻塞中的 goroutine 不一定触发异常，它只是等待同步条件。若条件永远不会满足，栈和仍可达的对象引用会持续存在，最终表现为 goroutine 数量和内存占用一起增长。