本文解析 go 程序因通道（channel）单向读写不匹配导致的死锁问题，重点说明为何递归写入无缓冲通道却仅单次读取会立即阻塞主协程，并给出可运行的修复方案与最佳实践。
本文解析 go 程序因通道（channel）单向读写不匹配导致的死锁问题，重点说明为何递归写入无缓冲通道却仅单次读取会立即阻塞主协程，并给出可运行的修复方案与最佳实践。
在 Go 中，向一个无缓冲通道（unbuffered channel） 发送数据时，发送操作会阻塞，直到有另一个 goroutine 同时执行对应的接收操作。这正是题中死锁的根本原因。
我们来逐段分析原始代码的问题：
func doSomething(c chan<p>⚠️ 注意：<code>result</code> 未定义，且函数名拼写错误（<code>dosomething</code> 应为 <code>doSomething</code>），但更关键的是——该函数试图无限递归地向通道写入，而每次写入都需同步配对的读取。</p><p>再看 <code>reads</code> 函数：</p><pre class="brush:php;toolbar:false;">func reads(c <p>它只从通道接收<strong>一个值</strong>，之后函数返回，goroutine 结束。而 <code>doSomething</code> 在 <code>main</code> 中是<strong>同步调用</strong>（非 <code>go doSomething(c)</code>），且首条 <code>c 就会永久阻塞——因为 <code>reads</code> 的 goroutine 虽已启动，但它只读一次就退出，无法消费后续（甚至首个）写入。</code></p><p>同时，<code>main</code> 函数本身也陷入阻塞：</p><pre class="brush:php;toolbar:false;">func main() {
go reads(c) // ❌ c 未声明初始化！编译失败
doSomething(c) // ❌ 同步调用，卡死在此
}此处还有两个硬性错误：
- 通道
c未声明和创建（缺少c := make(chan string)）； -
main协程在doSomething(c)处阻塞，而readsgoroutine 执行完即终止，无人持续接收，最终触发 panic:fatal error: all goroutines are asleep - deadlock!
✅ 正确做法：
- 显式创建通道（通常用无缓冲或合理容量的缓冲通道）；
-
确保读写并发且生命周期匹配——若要“持续读取”，
reads必须循环接收； -
避免在 main 中同步执行无限/阻塞操作；必要时用
go启动生产者，并通过信号（如donechannel 或sync.WaitGroup）协调退出。
以下是修复后的可运行示例：
package main import "fmt" func doSomething(c chan<p>? 关键要点总结： </p>
- 死锁三要素：所有 goroutine 都在等待（无一个能推进），通道无缓冲 + 写多读少 + 主协程阻塞 = 经典死锁；
-
range是读取通道的惯用安全方式，自动处理关闭信号； - 若需精确控制读写节奏，优先考虑带缓冲的通道（
make(chan T, N)）或使用select+default避免永久阻塞； - 永远不要在 main 中同步调用会永久阻塞的函数——除非你明确希望程序在此终止（且已确保其他 goroutine 能完成工作）。
遵循这些原则，即可避开 Go 并发中最常见的死锁陷阱。
