能读，但需确保生产者先关闭channel且仅由其关闭；消费者用range前须确认channel已关闭，否则会阻塞；动态生产者场景应改用select配合ok判断。
channel 关闭后还能不能读？别让 range 搞垮你的消费者
能读，但必须明确关闭时机，否则 range 会永久阻塞或 panic。生产者没关 channel，消费者用 range 就卡死；生产者关早了，消费者可能漏数据。
- 只允许生产者（且仅一个）调用
close()，消费者绝不能关 - 消费者用
for v := range ch前，确保所有生产者已退出并关闭 channel - 若生产者数量动态（比如启停 goroutine），改用
for { select { case v, ok := -
range底层就是不断recv直到收到关闭信号，没有超时、没有重试逻辑
多个生产者往同一个 chan int 写，怎么避免竞态和 panic？
channel 本身是并发安全的，写操作不会 panic，但「谁来关」「关几次」「数据是否完整」全靠你手动协调。
- 用
sync.WaitGroup记录生产者完成数：每个生产者结束前wg.Done()，主 goroutinewg.Wait()后再close(ch) - 禁止多个生产者都调用
close(ch)—— 第二次会 panic：panic: close of closed channel - 如果某个生产者因错误提前退出，也要
wg.Done()，否则消费者永远等不到关闭 - 不要依赖「写入次数」判断是否完成，比如
len(ch) == N—— channel 长度不可靠，且缓冲区可能未满就关闭
消费者要处理慢，怎么防止生产者被堵死？缓冲 channel 还是加超时？
取决于场景：实时性要求高就用带缓冲的 make(chan int, 100)；数据敏感不能丢就加 select 超时或使用 default 分流。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 无缓冲 channel：生产者会阻塞直到消费者取走，适合强同步、低吞吐场景
- 缓冲 channel：设大小要预估峰值流量，太大吃内存，太小仍会阻塞，
cap(ch)是硬上限 - 想丢弃新数据：用
select { case ch - 想等一会儿：用
select { case ch
为什么用 for range 消费时，程序不退出？
大概率是 channel 没被关闭，或者关闭发生在消费者启动之前 —— goroutine 启动是异步的，顺序不等于执行顺序。
- 别在 main 里直接
close(ch)然后启消费者：main 可能先关、消费者还没开始range - 典型错误：
go consume(ch); close(ch)→ 消费者可能刚进函数就遇到已关闭的 channel，range立即退出，看似“没干活” - 正确做法：用
sync.WaitGroup或chan struct{}显式通知消费者“可以开始了”，再由生产者统一关 - 调试时加一句
fmt.Printf("ch closed? %t\n", len(ch) == 0 && cap(ch) > 0)没用 —— 关闭状态无法通过长度判断，得靠ok返回值
实际最难的不是语法，是把「谁关」「何时关」「关完谁负责收尾」这几件事，在多个 goroutine 之间对齐。稍有错位，就会出现漏数据、假死、panic 三选一。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
