因为 channel 默认无缓冲，发送和接收必须同步配对；若只发送不接收或只接收不发送，goroutine 将在操作处永久阻塞。
channel 传数据时为什么 goroutine 会卡住
因为 channel 默认是无缓冲的，发送和接收必须成对阻塞等待。如果只发不收，或只收不发，goroutine 就会永久停在 ch 或 <code> 上。
常见错误现象：fatal error: all goroutines are asleep - deadlock
- 用
make(chan int, 0)（或直接make(chan int)）创建的是同步 channel，必须有配对操作 - 想单向发完就退出？加缓冲：
make(chan int, 10)，但要注意缓冲区满时仍会阻塞 - 不确定对方是否接收？加
select+default实现非阻塞发送
如何安全关闭 channel 并避免 panic
关闭已关闭的 channel 会 panic；从已关闭的 channel 接收会立即返回零值 + false（第二个返回值），但继续往里 send 会 panic。
使用场景：通知下游“数据发完了”，比如 worker pool 中任务分发结束。
立即学习“go语言免费学习笔记（深入）”；
- 只能由 sender 关闭，receiver 不应 close
- 关闭前确保所有发送已完成（常用
sync.WaitGroup等待） - 接收端用
for v, ok := 或 <code>range ch自动处理关闭 - 不要在多个 goroutine 中并发 close 同一个 channel
select 配合 channel 处理多路通信的典型写法
select 是 Go 并发控制的核心语法，用于在多个 channel 操作间做非阻塞或随机选择，但容易写错默认分支和超时逻辑。
性能影响：没有 case 可执行时，若含 default 则立即返回；否则阻塞，直到某个 channel 就绪。
- 超时控制必须用
time.After(d)或time.NewTimer()，别直接写time.Sleep -
default分支会让 select 变成“轮询”，慎用，尤其在高频循环中会吃 CPU - 同一个 channel 在多个 case 中重复出现是合法的，但 runtime 会随机选一个（不是按顺序）
- 示例：等待任意一个完成并取消其余：
select { case
channel 传递大对象时要不要用指针
channel 传输的是值拷贝。传 struct、slice、map 本身不深拷贝底层数据（slice header、map header 是小结构体），但传大 struct（比如含数组字段）或频繁发送，拷贝开销明显。
容易踩的坑：传指针后多个 goroutine 并发读写同一内存，没加锁就出竞态。
- 传
[]byte、string、map、slice本身开销小，通常不用改 - 传自定义 struct（>64 字节）建议用
*MyStruct减少拷贝 - 传指针 ≠ 线程安全，该加
sync.Mutex还得加 - 注意生命周期：别把栈变量地址传进 channel，goroutine 可能还在运行时栈已回收
channel 的本质是带同步语义的队列，不是消息总线，也不是共享内存替代品。真正难的从来不是怎么写，而是判断「该不该用 channel」——比如状态通知用 chan struct{}，结果聚合用 chan Result，而配置热更新、跨进程通信这些场景，它根本不是第一选择。
