本文详解 go 中向无缓冲通道写入数据时导致 goroutine 永久阻塞、defer 不执行、waitgroup 无法完成的根本原因，并提供安全关闭通道、同步读取与结构化并发的完整解决方案。
本文详解 go 中向无缓冲通道写入数据时导致 goroutine 永久阻塞、defer 不执行、waitgroup 无法完成的根本原因，并提供安全关闭通道、同步读取与结构化并发的完整解决方案。
在 Go 并发编程中，向无缓冲通道（unbuffered channel） 写入数据是一个同步操作：它会阻塞当前 goroutine，直到有另一个 goroutine 同时执行对应的接收操作。若主 goroutine 从未从该通道读取，所有写入 goroutine 将永远挂起——这正是你遇到问题的核心：c 阻塞了 receiveRss，导致 defer wg.Done() 永远不会执行，wg.Wait() 也就永不返回。
✅ 正确模式：写-读配对 + 显式关闭
解决的关键在于三点：
- 确保有 goroutine 读取通道（不能只写不读）；
- 在所有写入完成后关闭通道（通知读者“数据已发完”）；
-
使用
for range安全消费通道（自动退出，避免死循环）。
但注意：你的原始代码中存在一个严重逻辑错误——多个 goroutine 并发写入同一通道，却在每个 goroutine 内调用 close(c)。这会导致 panic（panic: close of closed channel），因为 close 只能调用一次，且必须由写端统一执行。
✅ 正确做法是：由主 goroutine 在所有写入 goroutine 启动后，等待它们全部完成（通过 WaitGroup），再关闭通道。
以下是修复后的完整、健壮、可运行示例：
package main
import (
"fmt"
"sync"
"github.com/SlyMarbo/rss" // 注意：此包已归档，生产环境请替换为现代 RSS 库（如 github.com/mmcdole/gofeed）
)
func main() {
urls := []string{
"http://rss.cnn.com/rss/edition.rss",
"http://rss.time.com/web/time/rss/top/index.xml",
}
c := make(chan string) // 保持 string 类型，更符合原始意图
var wg sync.WaitGroup
// 启动所有 worker goroutine
for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
feed, err := rss.Fetch(u)
if err != nil {
fmt.Printf("Failed to fetch %s: %v\n", u, err)
return
}
for _, item := range feed.Items {
select { // 增加 select 防止因 reader 提前退出导致写入阻塞
case c <h3>⚠️ 关键注意事项</h3>
-
不要在多个 goroutine 中调用
close(c)：仅由单一写端（通常是主 goroutine 或专用协调 goroutine）负责关闭。 -
避免在
range循环前调用wg.Wait()：否则主 goroutine 会卡住，无法进入range读取，造成死锁。应采用“启动 goroutine 关闭通道”的异步模式。 -
考虑使用带缓冲通道缓解压力：如
c := make(chan string, 100)可减少阻塞概率，但仍需最终关闭与读取。 -
生产环境务必添加超时与错误处理：RSS 抓取可能失败或耗时过长，建议结合
context.WithTimeout控制 goroutine 生命周期。 -
注意依赖包状态：
github.com/SlyMarbo/rss已不再维护，实际项目中请迁移至github.com/mmcdole/gofeed等活跃库。
遵循以上原则，即可确保通道通信安全、defer 正常执行、WaitGroup 准确计数，真正实现可控、可终止的 Go 并发流程。
