无缓冲channel发送后程序卡住怎么办

写Go代码时遇到无缓冲channel执行发送操作后程序卡住的情况，核心原因是无缓冲channel要求收发必须同步实时配对，没有对应的接收协程处理消息时发送逻辑就会永久阻塞，下面给出对应的解决方法和避坑要点。

无缓冲channel的发送操作永远不会单独完成，必须有另一个协程同时做好接收准备，两边同时到达对应代码行时才能完成数据传递，任意一侧先到都会陷入阻塞。

无缓冲 channel 发送后卡住，通常不是 Go 把数据吞了，而是发送端正在等待匹配的接收端。make(chan T) 的容量为 0，发送和接收必须在同一时刻配对；如果接收方没有启动、提前返回、监听了另一个 channel，发送就会一直等待。

先确认发送点是否一定能遇到同一个 channel 的接收点；如果业务只需要传递而不要求握手，再考虑有限缓冲；如果不能无限等待，就用 select 加超时或取消信号。

官方依据：https://go.dev/ref/spec#Channel_types、https://go.dev/ref/mem#Channel_communication。

先判断：发送为什么会卡住

最小的复现就是在同一个 goroutine 里先发送、后接收：

package main

func main() {
    ch := make(chan int) // 容量为 0，发送必须等到接收方就绪
    ch 

修复不是给发送语句加“等待”，而是让接收方在另一个 goroutine 中建立配对：

package main

import "fmt"

func main() {
    ch := make(chan int) // 无缓冲 channel 用来表达一次握手
    go func() {
        value := 

按负载和约束选择通信方式

把它当成一个小型架构选择问题会更容易：一次任务必须被对方立即接住时，用无缓冲 channel；生产者允许暂存少量任务时，用有限缓冲；调用方不能无限等时，给发送增加退出分支。

不要把缓冲容量当成根治死锁的开关。容量为 1 只能让一次发送先进入队列；如果接收方永远不消费，第二次发送仍会卡住。

排查三个经常被忽略的边界

接收方提前退出：接收循环因为错误、条件或 context 结束，但生产者仍继续发送。此时要让生产者也监听取消信号。

channel 实例不一致：发送方和接收方分别调用了两次 make(chan int)，类型一样却不是同一条通信线。把 channel 作为参数传递，避免在函数内部重新创建。

nil channel：var ch chan int 的值是 nil，对 nil channel 发送或接收都会永久阻塞。初始化前先检查生命周期，或让构造函数返回已经可用的 channel。

func produce(ctx context.Context, ch chan

用 select 给发送设置边界

当接收端可能因为负载、故障或退出而暂时不可用时，使用 select 将目标 channel、超时计时器和取消信号放到同一个决策边界：

func sendWithTimeout(ch chan

生产代码还应约定谁负责关闭 channel。通常由发送方在确认不会再发送时关闭；接收方用 value, ok := 或 for value := range ch 判断数据流是否结束，不要让多个发送方随意关闭同一条 channel。

落地清单与相关问题

• 发送和接收是否使用同一个 channel 实例？
• 接收 goroutine 是否真的启动，并且不会先返回？
• 是否需要无缓冲的握手语义，而不是暂存队列？
• 等待是否必须受 context 或超时约束？

无缓冲 channel 和缓冲 channel 的主要区别是什么？

无缓冲 channel 发送必须等接收方就绪；缓冲 channel 只要队列未满就能先放入值，但容量耗尽后仍然会阻塞。

为什么把 channel 容量改大后还是会卡？

因为容量只改变可暂存的数量，不会修复接收方退出、channel 实例错误或 nil channel；应先定位生命周期，再决定容量。