向已关闭的 channel 发送数据会立即引发 panic；go 语言规范明确规定，对关闭后的 channel 执行 send 操作是非法的，运行时将触发致命错误。
channel 关闭后继续发送数据会立即死锁
Go 的 chan 在已关闭状态下再调用 send（即 c ）会触发 panic，但更隐蔽的是：**向 nil channel 发送或接收，会永久阻塞**——这在 select 或 <a style="color:#f60; text-decoration:underline;" title="go" href="https://www.php.cn/zt/15863.html" target="_blank">go</a>routine 启动初期极易引发死锁。常见于未初始化的 channel 变量直接参与通信。
实操建议：
- 始终显式初始化 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。
实操建议：
- 所有
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，实际行为等价于死锁。
