Go channel是带同步语义的通信原语，发送/接收会阻塞直至配对就绪；必须用make创建，nil channel操作永久阻塞；类型区分读写方向；无缓冲channel要求收发goroutine同时就绪；关闭由发送方负责，重复关闭或接收方关闭均panic。
Go 语言的 channel 不是“用来传数据的管道”这种模糊说法就能讲清的——它本质是带同步语义的通信原语，发送和接收操作会阻塞，直到配对的另一端就绪。理解这一点，才能避开死锁、goroutine 泄漏等高频问题。
channel 创建必须指定类型且不能为 nil
声明但未初始化的 channel 是 nil，对它做发送或接收会永久阻塞（不是 panic）。必须用 make(chan T) 或带缓冲的 make(chan T, cap) 显式创建。
-
chan int和chan（只写）或（只读）类型不兼容，编译报错 - 缓冲区大小为 0 的 channel（即无缓冲 channel）要求收发 goroutine 同时就绪，否则阻塞；缓冲 channel 只有在缓冲满/空时才阻塞
- 避免在循环中反复
make(chan ...)，容易触发 GC 压力或泄漏
发送操作 会阻塞直到接收方准备就绪
向 channel 发送值的语法是 ch 。它不是“把数据塞进去就完事”，而是同步等待接收方从同一 channel 取走该值（无缓冲），或缓冲未满（有缓冲）。
- 如果接收方永远不出现（比如 goroutine 没启动、或已退出），发送操作将永久阻塞，导致整个 goroutine 卡住
- 可用
select+default实现非阻塞发送：select { case ch <- x: // 成功发送 default: // 缓冲满或无人接收，不阻塞 } - 向已关闭的 channel 发送会 panic：“send on closed channel”
接收操作 阻塞逻辑取决于 channel 状态
接收表达式 的行为分三种情况：有值可取（立刻返回）、channel 关闭且缓冲为空（返回零值+false）、channel 未关闭且空（阻塞）。
立即学习“go语言免费学习笔记（深入）”；
- 推荐用双赋值安全接收：
v, ok := ，其中ok为false表示 channel 已关闭且无剩余数据 - 直接写
v := 在 channel 关闭后仍会返回零值，但无法区分“收到零值”和“channel 关闭”，易引发逻辑错误 - 关闭 channel 应由发送方负责，接收方调用
close(ch)是无效操作，会 panic
关闭 channel 的时机与常见误用
close() 只表示“不再发送”，不释放 channel 内存，也不唤醒所有阻塞的接收者——它只影响后续的接收行为。
- 重复关闭同一个 channel 会 panic：“close of closed channel”
- 不要在多个 goroutine 中并发关闭同一 channel，需用 sync.Once 或明确的发送方生命周期管理
- 关闭前确保所有发送 goroutine 已退出，否则可能漏发数据或 panic
- 典型模式：用
sync.WaitGroup等待所有 sender 完成，再 close；receiver 用for range ch自动处理关闭
真正难的不是语法，而是判断“谁该关 channel”“什么时候关”“要不要加超时”“是否需要 select 多路复用”。这些决策直接影响程序是否死锁、是否丢失消息、是否泄露 goroutine——它们藏在业务逻辑里，不在 ch 这一行代码中。
