用无缓冲channel可实现最简生产者消费者模型：生产者发送时阻塞等待消费者接收，确保严格一一对应和强顺序；需由生产者在发完数据后调用close，消费者用for range自动退出，避免向已关闭channel发送或未检测关闭导致的panic和永久阻塞。
Go 语言原生用 channel + goroutine 就能干净实现生产者消费者模型，不需要锁、条件变量或第三方库——但错用 channel 容量、关闭时机或阻塞逻辑，反而会让程序死锁或漏数据。
如何用无缓冲 channel 实现最简版生产者消费者
无缓冲 channel 天然同步：生产者必须等消费者接收后才能继续，适合严格一一对应、低吞吐但强顺序的场景（比如日志采集链路中的逐条预处理）。
常见错误是往已关闭的 channel 发送数据，触发 panic；或消费者未用 range 且没检测关闭，导致 goroutine 永久阻塞。
- 生产者用
for循环发送，发送前不检查channel是否关闭 - 消费者用
for v := range ch，自动在channel关闭后退出 - 由生产者负责调用
close(ch)，且只能关一次 —— 通常在所有数据发完后
ch := make(chan int)
go func() {
for i := 0; i < 5; i++ {
ch <- i // 阻塞直到被消费
}
close(ch) // 必须关闭，否则消费者 range 不会结束
}()
for v := range ch {
fmt.Println("consumed:", v)
}为什么带缓冲 channel 更常用？容量设多少才合理
带缓冲 channel 解耦生产与消费速率，避免生产者因消费者慢而卡住。但缓冲区不是越大越好：过大会掩盖性能瓶颈，增加内存占用；过小则频繁阻塞，失去异步意义。
立即学习“go语言免费学习笔记（深入）”；
典型取值依据是「峰值写入速率 × 可接受延迟」。例如每秒生产 100 条、允许最多积压 2 秒，则缓冲设为 200；日志类场景常设 1024 或 4096，权衡响应性与内存。
- 创建：
ch := make(chan int, 1024) - 注意：
len(ch)返回当前队列长度，cap(ch)返回缓冲容量，二者都只读，不反映是否阻塞 - 消费者仍推荐
range，但生产者不能假设ch 立即返回——若缓冲满，仍会阻塞
多个生产者 / 多个消费者怎么安全协作
多个生产者往同一 channel 写是安全的，多个消费者从同一 channel 读也是安全的 —— Go 运行时保证 channel 操作原子性。真正要小心的是「谁关 channel」和「怎么知道所有生产者结束了」。
错误做法：每个生产者都调用 close(ch) → panic；或消费者提前退出，导致部分数据无人接收。
- 用
sync.WaitGroup让主 goroutine 等所有生产者完成，再统一close(ch) - 消费者数量可动态启停，只要确保至少一个在运行，且都用
range即可 - 若需精确控制消费者生命周期（如限速、失败重试），把
channel作为输入参数传入每个消费者 goroutine，避免共享状态
真实项目中容易被忽略的三个细节
实际跑在线上时，最容易出问题的不是逻辑，而是边界和可观测性。
-
channel被 GC 掉但仍有 goroutine 在等待 → 使用前确认生命周期，避免悬空引用 - 消费者 panic 后未 recover，导致该 goroutine 退出，后续数据堆积 → 消费逻辑外层加
defer recover() - 无法监控
channel积压量和消费延迟 → 用len(ch)定期采样上报，或改用带超时的select判断是否拥塞
复杂点从来不在模型本身，而在你是否清楚每一行 ch 和 的阻塞条件、关闭责任和异常路径。
