Go 不提供运行时死锁检测 API，死锁是全局调度终态而非单次操作属性；务实做法是通过超时控制和非阻塞 select（带 default 或 case）避免无限阻塞。
Go 本身不提供运行时死锁检测 API，runtime.Goexit 或 select 语句无法主动“预测”死锁；你写的函数不能“检测并避免”死锁——它只能通过设计约束来大幅降低发生概率。真正能被干预的，是那些因通道使用不当导致的可复现阻塞行为。
为什么 select 默认会 panic 而不是“检测死锁”
Go 运行时在所有 goroutine 都阻塞且无其他活跃 goroutine 时，才会触发 fatal error: all goroutines are asleep - deadlock!。这不是函数能拦截的错误，而是整个程序的终态判断。你无法在某个 send 或 recv 调用前调用一个“死锁检查函数”来返回 true/false —— 因为死锁是全局调度状态，不是单次操作的属性。
所以务实做法是：把“避免死锁”转化为“让通道操作不无限阻塞”，核心手段就是超时控制和非阻塞尝试。
-
select必须带default或case ，否则可能卡住 - 永远不要在没有缓冲、且无并发接收者的情况下对
chan int执行同步ch - 用
len(ch) 判断缓冲通道是否“大概率可写”，但这只是快照，不保证原子性
用 select + time.After 实现带超时的发送/接收
这是最常用、最可控的防阻塞方式。它不检测死锁，但能防止 goroutine 卡死在某次操作上。
// SafeSend 尝试在 timeout 内向 ch 发送 val，失败返回 false
func SafeSend[T any](ch chan<- T, val T, timeout time.Duration) bool {
select {
case ch <- val:
return true
case <-time.After(timeout):
return false
}
}
<p>// SafeRecv 尝试在 timeout 内从 ch 接收，成功返回值和 true
func SafeRecv[T any](ch <-chan T, timeout time.Duration) (T, bool) {
var zero T
select {
case val := <-ch:
return val, true
case <-time.After(timeout):
return zero, false
}
}注意：time.After 会启动一个 timer，短超时（如 time.NewTimer 并 Reset。
用 select + default 实现非阻塞操作
适用于“有就拿，没有就算”的场景，比如消费工作队列时不想等。
func TryRecv[T any](ch <-chan T) (T, bool) {
var zero T
select {
case val := <-ch:
return val, true
default:
return zero, false
}
}
<p>func TrySend[T any](ch chan<- T, val T) bool {
select {
case ch <- val:
return true
default:
return false
}
}关键点：
-
default分支让 select 立即返回，不挂起 goroutine - 对无缓冲通道，
TrySend几乎总是返回false（除非恰好有 goroutine 同时在recv） - 对满缓冲通道，
TrySend返回false；对空缓冲通道，TryRecv返回false
缓冲通道容量与 goroutine 协作才是根本预防手段
很多所谓“死锁”其实源于通道容量和生产/消费速率不匹配。例如：
- 创建
ch := make(chan int, 0)（无缓冲），却只启动 sender，没启 receiver → 必然死锁 - 创建
ch := make(chan int, 1)，连续调用两次SafeSend(ch, x, 100*time.Millisecond)→ 第二次大概率超时，但程序不会死锁 - 用
range遍历通道但忘记 close → 接收端永久阻塞（不是死锁，除非 sender 也退出）
真正要花时间设计的，是通道生命周期管理：谁负责 close？goroutine 是否按预期启动？是否有 panic 导致 defer close(ch) 未执行？这些比写一个“检测函数”重要得多。
