向已关闭的 channel 发送数据会立即引发 panic；Go 语言规范明确规定，对关闭后的 channel 执行 send 操作是非法的，运行时将触发致命错误。
channel 关闭后继续发送数据会立即死锁
Go 的 chan 在已关闭状态下再调用 send（即 c ）会触发 panic，但更隐蔽的是：**向 nil channel 发送或接收，会永久阻塞**——这在 select 或 goroutine 启动初期极易引发死锁。常见于未初始化的 channel 变量直接参与通信。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终显式初始化 channel，避免零值：
c := make(chan int, 1)，而非声明后未赋值 - 关闭前确认 sender 已全部退出；用
sync.WaitGroup或context协调生命周期 - 在 select 中使用
default分支防止单一 channel 阻塞，但注意这不解决根本的关闭时机问题 - 调试时加
go tool trace或启用GODEBUG=schedtrace=1000观察 goroutine 状态
goroutine 泄漏导致资源耗尽型“类死锁”
这不是编译器报 fatal error: all goroutines are asleep - deadlock! 的典型死锁，而是大量 goroutine 持续阻塞在 channel 接收、time.Sleep、或未响应的 HTTP 客户端上，最终内存爆掉或调度器卡死。典型场景是忘记从 channel 读取、或 HTTP 调用没设 timeout。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有
http.Client必须设置Timeout或用context.WithTimeout控制请求生命周期 - 向带缓冲 channel 发送时，确保有对应接收方；无缓冲 channel 更要严格配对
- 用
runtime.NumGoroutine()在关键路径打点，异常增长时触发告警 - 避免在循环中无条件启 goroutine：
for range data { go f(x) }应加 worker pool 或限速
select 语句中 default 分支掩盖了逻辑错误
select 带 default 看似“非阻塞”，但若本该等待某个 channel 就绪却因 default 快速跳过，会导致业务逻辑丢失（比如漏处理信号、跳过关键状态更新），后续依赖该状态的 goroutine 就可能永久等待——表面没 panic，实际行为等价于死锁。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅在明确需要“尝试发送/接收，失败就做别的事”时才用
default；否则优先用阻塞操作 + context 控制超时 - 把
select和 channel 生命周期绑定：例如用ctx.Done()作为退出信号，比裸default更可靠 - 测试时可临时删掉
default，观察是否真出现阻塞，验证 channel 是否真的会被写入/读取
sync.Mutex 误用造成 goroutine 永久等待
死锁不一定来自 channel。对同一个 sync.Mutex 多次 Lock()（未 Unlock）会导致后续 goroutine 在 Lock() 处无限等待；跨 goroutine 传递已加锁的 mutex、或 defer Unlock 但 panic 发生在 lock 之后未执行 defer，都会触发类似问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 坚持“lock/unlock 成对出现在同一作用域”，优先用
defer mu.Unlock()，且紧跟mu.Lock() - 避免在持有锁时调用可能阻塞或不可控的外部函数（如 HTTP 请求、数据库查询）
- 不要复制已使用的
sync.Mutex变量；它不是线程安全可拷贝类型，复制后解锁原变量不影响副本 - 用
-race编译并运行测试，能捕获大部分锁误用和竞态，但无法发现纯逻辑死锁
真正难排查的死锁，往往混合了 channel 关闭时机错乱、goroutine 启动条件缺失、以及锁范围过大这几个因素。与其等 runtime 报错，不如在设计阶段就明确每个 channel 的 owner、每个 goroutine 的退出条件、每把锁的临界区边界。
