Go channel 缓冲区满后发送方为什么一直等待

排查 Go 并发程序时，如果日志停在 jobs ，而 jobs 是带缓冲 channel，最常见的原因不是发送语句失效，而是缓冲区已经没有空位，同时没有接收方继续取值。缓冲区只负责暂存有限数量的元素，不能把生产速度永久变成无限队列；只要没有消费动作，发送方就会按 channel 的同步语义等待。

先看 cap(jobs) 和 len(jobs)，再确认接收循环是否还活着。缓冲区满时，恢复接收方通常才是根治；如果消息允许丢弃或超时，则用 select 为发送提供退出路径。

先看缓冲区满时发送语句卡在哪里

make(chan T, n) 的第二个参数是容量。容量为零时，发送和接收必须同时就绪；容量大于零时，发送可以先把值放进缓冲区，但当已入队元素达到容量，下一次发送就会阻塞。len 只能帮助观察当前积压，不能说明消费者一定存在。

package main

import "fmt"

func main() {
	jobs := make(chan int, 2)
	jobs 

上例的关键不是数字 2，而是“生产端继续写、消费端没有读”。生产者可能是 HTTP 请求、定时任务或文件解析 goroutine；只要它们共享同一个已满 channel，阻塞就会沿调用链向上传播。

处理方案：先恢复消费，再判断是否需要背压

无损任务队列的第一选择是让消费者持续读取，并把退出条件写进同一套生命周期。消费者提前返回、只读一次，或者被另一个错误分支取消，都会留下“生产者还在发、没人再收”的现场。

func worker(jobs 

现场判断可以按下面的顺序做：先确认是否存在接收循环，再确认接收循环是否因错误提前返回，最后确认关闭和取消是否由约定的协调方负责。不要一看到阻塞就只把容量从 100 改成 10000；这只会把积压搬到更晚的时刻。

允许放弃时，用 select 给发送增加出口

如果 channel 传的是刷新提示、统计采样或可以重试的通知，发送方不必无限等待。default 表示当前没有立即可用的发送机会就继续执行；超时和取消则把等待上限交给业务规则。

func trySend(jobs chan

这里的返回值必须被调用方处理：返回 false 可以计数、记录采样日志，或者改走降级路径。若消息不能丢，就删掉 default，改用持续消费者或有界超时，并把失败交给上层。

关闭责任和复查清单要一起固定

关闭 channel 不是“让发送方解堵”的通用按钮。关闭后继续发送会触发 send on closed channel；接收方可以通过双值接收知道 channel 已关闭，但谁关闭必须有明确约定。通常由生产端或拥有队列生命周期的一方，在确认不会再有发送后关闭。

复查时记住四件事：容量是否真的符合峰值积压；消费者是否有持续循环和错误退出记录；可丢消息是否有 select 出口；关闭动作是否只有一个责任方。这样既能解释“为什么一直等待”，也能避免用盲目扩容把故障推迟到内存和延迟上。

常见问题

缓冲 channel 满了是不是 goroutine 死锁？

不一定。它可能只是正常背压，等消费者恢复后会继续；只有所有相关 goroutine 都在互相等待、且没有可达的解除条件时，才构成死锁现场。

把 channel 容量调大能彻底解决吗？

不能。它只增加暂存空间。生产速度长期高于消费速度时，阻塞仍会出现，甚至积压更多任务。

为什么加了 default 后消息少了？

default 会让发送在当前不可用时立即返回；如果消息不能丢，应改为持续消费、超时重试或把失败交给可靠队列，而不是静默丢弃。