本文详解 go 中无缓冲通道（unbuffered channel）的阻塞机制，指出 `chin
在 Go 并发编程中，通道（channel）是 Goroutine 间通信的核心机制，但其行为高度依赖于缓冲策略与收发协程的生命周期协同。你遇到的“程序卡在 chin <- vin”现象，并非代码逻辑错误，而是对无缓冲通道语义的典型误解。
? 根本原因：无缓冲通道的同步特性
Go 中，未指定容量的 make(chan T) 创建的是无缓冲通道——它不保存任何值，仅作为通信的“握手点”。这意味着：
- 发送操作 chin <- vin 必须等待至少一个 Goroutine 正在执行 <-chin 接收，二者才会同时完成；
- 若所有 worker() 尚未进入 for res := range chin 循环（例如刚启动、被调度延迟或因其他原因阻塞），发送将永久挂起；
- 这正是你观察到“恰好卡在第 5 次发送”的原因：5 个 worker 启动后可能尚未全部就绪接收，而你的主 goroutine 在发送端单线程串行执行，一旦首个发送阻塞，后续循环无法继续。
✅ 关键结论：无缓冲通道本身永远是“阻塞式”的；所谓“非阻塞”，只能通过架构设计（如启用接收者、添加缓冲、使用 select 带 default）来规避。
✅ 方案一：启用缓冲通道（推荐用于可控数据量）
为 chin 和 chout 添加合理缓冲容量，使发送端可暂存数据，避免强同步依赖：
// 修改全局声明（示例：缓冲区大小设为 100） var chin = make(chan in, 100) // 允许最多 100 个待处理任务 var chout = make(chan out, 100) // 允许最多 100 个待更新结果
⚠️ 注意事项：
- 缓冲大小需根据内存与业务负载权衡：过大易 OOM，过小仍可能阻塞；
- 缓冲仅缓解问题，不解决 Goroutine 生命周期管理——仍需确保 worker() 持续运行且最终关闭通道。
✅ 方案二：解耦发送与接收流程（更健壮的生产级实践）
将结果消费逻辑移至独立 goroutine，主 goroutine 专注生产，彻底消除发送/接收的时序耦合：
// 启动工作协程（保持不变）
for i := 0; i < 5; i++ {
go worker()
}
// 主 goroutine：只负责发送任务
go func() {
defer close(chin) // 所有任务发送完毕后关闭 chin，通知 worker 退出
rows, err := nextbatch2.Query()
if err != nil {
panic(err)
}
defer rows.Close()
for rows.Next() {
var id int
var data string
if err := rows.Scan(&id, &data); err != nil {
panic(err)
}
chin <- in{ID: id, Data: data} // 现在即使 worker 稍慢，缓冲或调度也会保障发送完成
}
}()
// 主 goroutine：立即启动结果消费（独立 goroutine）
go func() {
defer close(chout) // 可选：若 chout 仅被主 goroutine 消费，此处可不关
for res := range chout {
if _, err := update5.Exec(res.Data, res.ID); err != nil {
log.Printf("update failed: %v", err)
}
}
}()
// 主 goroutine 等待所有任务完成（关键！）
// 使用 sync.WaitGroup 或信号 channel 更佳，此处简化为等待 chin 关闭后手动计数
// ...（实际中建议用 WaitGroup 跟踪 worker 完成）同时，修正 worker 函数以响应 chin 关闭：
func worker() {
for res := range chin { // range 自动在 chin 关闭且读完后退出
v := out{
ID: res.ID,
Data: process(res.Data),
}
chout <- v
}
}⚠️ 必须遵守的通道最佳实践
range 需配 close()：
for v := range ch 会持续阻塞直到 ch 被 close()。若忘记关闭，循环永不结束——这是你原代码中 Processing out channel... 不打印的另一潜在原因。避免在 range 中关闭通道：
多个 goroutine 同时 close(ch) 会 panic。应由唯一生产者（如上述 go func(){... close(chin)}）负责关闭。错误处理不可省略：
数据库操作（rows.Scan, update5.Exec）必须检查 err，而非直接 panic，否则异常时程序崩溃，资源无法释放。资源清理：
rows.Close() 应置于 defer 中，确保无论循环是否完成均执行。
✅ 总结：三步构建健壮通道流水线
| 步骤 | 操作 | 目的 |
|---|---|---|
| 1. 通道初始化 | make(chan T, N) 设置合理缓冲（N ≥ 并发 worker 数 × 预期峰值任务数） | 解耦生产/消费速率差异 |
| 2. 生产者设计 | 启动 goroutine 发送数据 → defer close(chin) | 显式标记生产结束，驱动 range 退出 |
| 3. 消费者设计 | for range ch + close(chout)（如需）+ 错误日志 | 安全、可中断、可观测的结果处理 |
遵循以上原则，你的数据库批处理流水线将不再因通道阻塞而挂起，真正实现高并发、低延迟、易维护的 Go 并发模式。
