Go channel 缓冲区满时发送方如何用 context 退出

Go 的缓冲 channel 满载后，发送方不是“丢弃”数据，而是会等待直到消费者取走一个元素。要让这段等待可以退出，做法是在同一个 select 中同时等待 ch 和 ；取消发生时返回 ctx.Err()。缓冲容量只能吸收有限的突发，不能替代取消机制。

先确认发送为什么会卡住：缓冲区只解决有限排队

语言规范规定，缓冲 channel 只有在缓冲区有空间时发送才能继续；空间用完后，发送操作会等待接收者。下面这几个量决定了现场现象：

因此，单纯把容量从 10 改成 100，只是把阻塞推迟。更稳妥的边界是：生产者每次准备发送前都能观察任务是否取消。

用 select 给发送操作加上 context.Done 分支

把发送封装成返回错误的函数，调用方就能区分“已放入 channel”和“任务已取消”。WithCancel 创建的派生 context 会在调用 cancel 或父 context 结束时关闭 Done channel；超时 context 也遵循同一观察方式。

package main

import (
    "context"
)

// sendWithContext 让一次发送同时具备成功和取消两个出口。
func sendWithContext[T any](ctx context.Context, ch chan

这里没有用轮询 len(ch) 判断空间，因为检查和发送不是一个原子动作：检查通过后，另一个 goroutine 仍可能先占用槽位。select 直接等待通信事件，才能把“可发送”与“已取消”放进同一个同步点。

在生产循环中传递取消结果并清理资源

实际代码通常不是发一个值，而是循环生产。收到错误就要立刻停止循环；如果继续调用发送函数，只会重复得到取消错误或制造无意义工作。创建派生 context 的函数还应在返回路径调用 cancel，及时释放相关资源。

func produce(ctx context.Context, out chan

如果消费者提前结束，应该由它或更上层调用 cancel，让生产者的 分支可达。若多个生产者共用一个输出 channel，不要让其中一个生产者随意 close(out)；通常由明确的拥有者在确认所有发送者结束后关闭。

四个容易误判的退出边界

• 只用缓冲容量：容量不是超时，消费者停摆后仍会卡住。
• 只在循环外检查 ctx.Err：检查后到发送之间仍可能阻塞，取消分支必须和发送放在同一个 select。
• 把 context 存进结构体：标准库建议把 context 作为函数的显式首参数传递，不要用它承载可选业务参数。
• 忽略 select 的竞争：当发送和 Done 同时就绪时，select 可能选择任一就绪分支；若业务必须“取消后绝不再接收新值”，应在发送成功后再次检查取消状态，或由协议层定义可接受的竞态窗口。

常见问题

发送到已关闭的 channel 能靠 context 避免 panic 吗？

不能。向已关闭 channel 发送会触发 panic；context 只负责取消等待，不负责改变 channel 的关闭状态。先设计好 channel 的拥有者和关闭时机。

为什么不直接用 time.After 判断发送超时？

可以做一次性超时，但请求级代码更适合让上游传入带 deadline 的 context，这样同一个取消信号能贯穿生产、发送和下游调用。