channel 用于 goroutine 安全传递数据并天然同步；相比全局变量加锁，它避免漏锁、死锁，且同步逻辑内建于语法中，如 result := <-ch 一行即可等待。
Go 的 channel 不是用来“共享内存”的，而是用来**让 goroutine 安全地传递数据并天然同步**——它既是通信管道，也是控制开关。
为什么用 channel 而不是全局变量或锁？
直接读写全局变量 + sync.Mutex 容易漏锁、死锁、或忘记 unlock；而 channel 强制你“发完再收”或“收完才发”，同步逻辑内建在语法里。比如两个 goroutine 协作计算结果，用 channel 就一行等待：result := ，不用管谁先跑、谁后跑、要不要加锁。
- 无缓冲
ch := make(chan int)：发送即阻塞，直到有人接收 —— 天然实现“等待完成” - 带缓冲
ch := make(chan int, 10)：能暂存 10 个值，生产者不必等消费者立刻处理，适合批量任务或 I/O 预取 - 方向限定如
func worker(in ：编译期就能防止误写（往只读 channel 发送会报错）
怎么安全关闭 channel 并避免 panic？
只有发送方能调用 close(ch)；接收方检测是否关闭，靠 val, ok := 中的 <code>ok 值。如果对已关闭的 channel 再次发送，会 panic；如果对 nil channel 接收，会永远阻塞。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 切忌在多个 goroutine 中重复
close(ch)—— 会 panic - 消费者用
for range ch最省心，它自动在 channel 关闭后退出循环 - 别用
close(nil)，也别在未初始化的 channel 上操作（var ch chan int是 nil）
select 怎么防超时和避免 goroutine 泄露？
select 是多路 channel 监听器，但写错就容易卡死或漏响应。典型错误是只监听一个 channel 却没 default 或超时分支，导致整个 goroutine 挂起。
立即学习“go语言免费学习笔记（深入）”；
- 想非阻塞收数据？加
default分支：select { case x := - 想设超时？用
，不是 <code>time.Sleep - 别在循环里反复创建新 channel 或 goroutine 却不回收 —— 这是 goroutine 泄露高发场景
真正难的不是语法，而是判断：这个 channel 该带缓冲还是不带？谁负责关？要不要加 context 控制生命周期？这些决策一旦定错，程序可能在线上跑几天才暴露死锁或内存暴涨。
