当对未关闭的无缓冲通道使用 `for range` 时，循环会在所有数据读取完毕后持续阻塞等待新值，而若发送方已全部退出且未关闭通道，程序将陷入死锁。
在 Go 中，for ele := range ch 是一种简洁安全的通道遍历语法，但它有一个关键前提：该通道必须被显式关闭（close(ch)），否则循环永远不会结束——它会一直阻塞，等待下一个值到来，即使所有 goroutine 已完成发送。
你的代码中存在典型的“未关闭通道导致死锁”问题：
my_channel := make(chan int) // 无缓冲通道
for i := 2; i < 5; i++ {
go sum_up(i, my_channel) // 启动 3 个 goroutine，各发 1 个值
}
for ele := range my_channel { // ✅ 成功读取 1、3、6
fmt.Println(ele)
} // ❌ 此处卡住：无更多数据，且通道未关闭 → 死锁虽然三个 sum_up goroutine 已成功向通道发送了 0+1=1、0+1+2=3、0+1+2+3=6 并退出，但主 goroutine 的 range 循环并不知道“发送已全部完成”。Go 的通道模型中，只有关闭通道才能向 range 发出“不会再有新值”的信号；单纯等待发送方退出是不够的——因为无法保证它们是否真的已完成（可能存在竞态或延迟）。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
✅ 正确做法：协作式关闭通道
需引入同步机制（如 sync.WaitGroup），让主 goroutine 确认所有发送者完成后再关闭通道：
package main
import (
"fmt"
"sync"
)
func sum_up(my_int int, cs chan int, wg *sync.WaitGroup) {
defer wg.Done() // 确保无论何种路径都调用 Done()
my_sum := 0
for i := 0; i < my_int; i++ {
my_sum += i
}
cs <- my_sum
}
func main() {
wg := &sync.WaitGroup{}
my_channel := make(chan int)
// 启动 goroutine 并注册等待
for i := 2; i < 5; i++ {
wg.Add(1)
go sum_up(i, my_channel, wg)
}
// 单独 goroutine 等待全部完成并关闭通道
go func() {
wg.Wait()
close(my_channel) // ? 关键：通知 range 循环终止
}()
// 安全遍历：收到所有值后自动退出
for ele := range my_channel {
fmt.Println(ele)
}
fmt.Println("Done")
}? 注意：close() 必须由发送方或协调者调用，且只能调用一次；对已关闭通道再次 close 会 panic。此处由独立 goroutine 调用，避免主 goroutine 在 range 前就关闭（导致漏读）或在 range 后才关闭（导致死锁）。
? 替代方案（更现代推荐）
若使用 Go 1.21+，可考虑 errgroup.Group 或结合 context 实现超时控制；但对于本例，WaitGroup + close 是最清晰、零依赖的标准解法。
✅ 总结
- for range ch 会阻塞直到通道被关闭；
- 发送 goroutine 退出 ≠ 通道可安全关闭，需显式同步；
- 使用 sync.WaitGroup 是协调多 goroutine 发送后关闭通道的惯用模式；
- 切勿在发送未完成前关闭通道，也切勿遗漏关闭——二者均会导致逻辑错误或死锁。
遵循这一模式，即可写出健壮、无死锁的并发通道处理代码。
