select 没 default 容易卡死，因所有 case 阻塞时 goroutine 挂起，主 goroutine 无其他协程则触发死锁；需用 default 非阻塞轮询或 time.After 超时控制。
为什么 select 没 default 就容易卡死
Go 的 select 在所有 case 都阻塞时会直接挂起当前 goroutine，如果这是主 goroutine 且没其他活跃协程，程序就死锁。这不是 bug，是设计使然——它要求你明确处理“无事可做”的情况。
常见错误现象：fatal error: all goroutines are asleep - deadlock!，尤其出现在只读或只写 channel、没加 default 也没关 channel 的循环里。
- 使用场景：等待多个 channel 事件（如超时、信号、数据到达），但漏掉兜底逻辑
- 正确做法：加
default分支做非阻塞轮询，或配合time.After做超时控制 - 性能影响：纯
default会导致空转，高频率下建议搭配runtime.Gosched()或小延时
示例：
select {
case v := <-ch:
fmt.Println(v)
default:
fmt.Println("channel empty, skip")
time.Sleep(time.Millisecond) // 防止忙等
}
close() 后继续写入 channel 会 panic，但读完不关也会死锁
向已关闭的 channel 写入会触发 panic: send on closed channel；但反过来，不关 channel，接收方永远等下去，一旦发送方退出、无其他 goroutine 活跃，就死锁。
- 使用场景：生产者-消费者模型中，生产者结束前必须
close(ch)，消费者用for v := range ch安全退出 - 参数差异：
close()只能对 chan - 容易踩的坑：在 goroutine 中 close，但主 goroutine 没等它结束就退出；或多个 goroutine 争抢 close 同一个 channel
安全模式：
go func() {
defer close(ch)
for _, item := range data {
ch <- item
}
}()
for v := range ch { // 自动停在 close 后
process(v)
}
调试死锁：go tool trace 比 pprof 更直接
pprof 的 goroutine profile 只能看到栈，而 go tool trace 能还原 goroutine 状态变迁，一眼看出谁在等谁、等了多久、是否永久阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 启用方式：启动时加
import _ "net/http/pprof"和go tool trace所需 runtime 支持，或直接用runtime/trace - 关键操作：运行程序后访问
http://localhost:6060/debug/trace下载 trace 文件，再用go tool trace trace.out查看可视化时间线 - 兼容性注意：Go 1.20+ 默认启用更细粒度调度追踪，旧版本可能看不到 channel 阻塞点，建议升级
典型线索：trace 图中某 goroutine 长时间处于 “GC waiting” 或 “chan recv” 状态，且无对应 sender 唤醒，基本就是死锁源头。
带缓冲 channel 不等于免死锁，缓冲区满/空仍是阻塞点
很多人以为 ch := make(chan int, 10) 就不会阻塞，其实只是把阻塞时机延后了：发第 11 个值时仍会卡住，收空后继续读也一样卡。
- 使用场景：用于削峰填谷，但不能替代逻辑上的完成通知（比如用缓冲 channel 替代
sync.WaitGroup是危险的） - 性能影响：缓冲区越大，内存占用越高，且无法解决“发送方不知道接收方是否还在”的根本问题
- 容易被忽略的地方：用
len(ch) == cap(ch)判断是否满，但这不是原子操作，多 goroutine 下不可靠；应改用select+default尝试发送
安全写法：
select {
case ch <- v:
// 成功
default:
// 缓冲区满，丢弃或重试
}
死锁最麻烦的不是报错，而是它只在特定数据流、特定并发节奏下才触发。上线前光跑单元测试不够，得用真实压测流量 + go tool trace 抓几次长周期运行快照，不然等到凌晨三点看 all goroutines are asleep 就晚了。
