Go 的 goroutine 不会因循环引用无法释放；真正卡住的原因是未关闭 channel 导致阻塞，或闭包捕获大对象拖慢资源回收，应明确关闭责任、精简闭包捕获、优先使用 context 控制生命周期。
goroutine 本身不会因“循环引用”被卡住不退出
先说结论：Go 的 goroutine 没有“循环引用导致无法释放”这回事。GC 不按引用计数清理 goroutine，而是看它是否还在运行、是否阻塞在未关闭的 channel 上、有没有被其他活跃 goroutine 持有栈帧——和对象间的强引用无关。
你真正遇到的，往往是以下两种情况之一混在一起说成了“循环引用”：
- goroutine 持有对某个
struct或闭包的引用，而该结构又反向持有对 channel / context / 其他 goroutine 的引用，造成逻辑上“互相等” - 更常见的是：goroutine 卡死在
for range ch或<-ch上，因为没人关ch，它就永远等下去 —— 这不是循环引用，是通道没关闭
for range channel 卡死：没关 channel 是主因
写法如 for v := range ch { ... } 的 goroutine，只要 ch 没被关闭，它就不会退出。哪怕所有发送方都结束了、甚至退出了，只要没显式调用 close(ch)，接收方就永远阻塞。
典型错误模式：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan int)
go func() {
for v := range ch { // ← 此处会一直等，直到 close(ch)
fmt.Println(v)
}
}()
// 忘记 close(ch)，或 close 时机不对（比如在发送 goroutine 之前）
修复要点：
- 明确谁负责关闭：通常是最后一个发送方，或协调者（如使用
sync.WaitGroup等待全部发送完成后再close(ch)） - 避免重复 close：
close只能调一次，多次 panic - 别在发送方里直接 close —— 如果有多个发送 goroutine，必须确保只有一个执行
close
闭包捕获变量导致 goroutine 持有不该持有的资源
这不是循环引用，但效果类似：一个 goroutine 在启动时捕获了某个大对象（比如整个 *http.Request、map[string]*User），而这个对象又包含指向数据库连接、文件句柄或另一个 channel 的指针。goroutine 虽小，却拖着一整棵树不释放。
常见于这类写法：
data := bigStruct{}
go func() {
use(data) // data 被整个捕获，即使只用其中一两个字段
}()
建议做法：
- 只传真正需要的字段：
go func(id int, name string) { ... }(data.ID, data.Name) - 避免在闭包中直接引用大结构体或全局 map；改用 ID 查找或显式拷贝关键字段
- 若必须传结构体，确认它不含未关闭的资源（如未
Close()的*os.File）
context.Done() 比 channel 更适合控制 goroutine 生命周期
用 context.Context 替代自定义 done channel，能更清晰地表达“这个 goroutine 应该什么时候停”。尤其当存在嵌套或超时需求时，context 自动传播取消信号，不容易漏关。
错误示范：
done := make(chan struct{})
go func() {
select {
case <-done:
return
case v := <-ch:
handle(v)
}
}()
// 忘记 close(done)
正确写法：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // 确保 cancel 被调用
go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
return // 自动响应超时或手动 cancel
case v := <-ch:
handle(v)
}
}
}(ctx)
真正容易被忽略的点是：cancel 函数本身也得被调用，而且不能只在成功路径上 defer —— 如果启动 goroutine 失败，也要 cancel，否则 ctx 会泄漏。
