无缓冲channel一发就死锁，因其是同步通道：发送操作会立即阻塞，必须有另一goroutine同时执行接收操作才能配对完成，否则所有goroutine休眠触发deadlock。
无缓冲 channel 为什么一发就死锁？
因为它是同步通道：ch 这一行会卡死，直到有另一个 goroutine 正好在执行 <code>。主 goroutine 自己不启接收协程，又没配对，结果所有 goroutine 都 asleep，直接报 <code>fatal error: all goroutines are asleep - deadlock!。
- 必须配对：一个 goroutine 发，至少一个 goroutine 收（不能是同一个 goroutine 先发后收）
- 调试时加
fmt.Println("before send")和fmt.Println("after send")，如果只看到前一句，基本就是卡在发送上了 - 适合场景：goroutine 启动通知、任务完成信号、精确控制执行节奏（比如等某件事做完再继续）
用 channel 做“完成信号”怎么写才安全？
别用 ch := make(chan int) 然后 ch 就完事——接收端没启动，必死锁。正确做法是让 sender 和 receiver 在不同 goroutine 中，且 receiver 要提前或同步就位。
- 典型模式：sender 发一个零值（如
struct{}{}），receiver 用阻塞等待 - 用
chan struct{}而不是chan int，省空间、语义清、零值无歧义 - 关闭通道不是必须的；若要用，只由 sender 关闭，receiver 绝不调
close(ch)
go func() {
doWork()
ch <- struct{}{} // 通知完成
}()
<-ch // 主 goroutine 等在这里select + default 为什么比纯阻塞更适合信号场景？
纯 会无限等待，一旦信号没来，程序就卡住。而 <code>select 可以加超时或非阻塞兜底，避免逻辑僵死。
-
default分支让接收变成“尝试读”，不阻塞，适合轮询或降级处理 - 搭配
time.After可实现带超时的等待，防止依赖方失联拖垮主流程 - 注意：
select是随机选就绪分支，多个 case 都 ready 时不会按顺序执行
select {
case <-done:
fmt.Println("收到完成信号")
default:
fmt.Println("没等到信号，继续干别的")
}channel 关闭后还能读吗？怎么判断是不是真关了？
能读，但行为分情况：无缓冲 channel 关闭后读，立刻返回零值 + false；有缓冲 channel 关闭后，先读完缓存数据，之后才返回零值 + false。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
v := —— 如果 <code>ch已关，v是0（int 类型），你以为任务还在跑，其实早就结束了 - 正确写法：
v, ok := ，用 <code>ok判断是否还有有效数据 - 关闭前确保没人再往里写；重复
close(ch)会 panic
通道不是管道开关，也不是计时器替代品。它传递的是“发生过什么”，而不是“现在是什么状态”。用错一次，轻则死锁卡住，重则 panic 崩溃，且错误现场往往不报具体行号。
