Go 非阻塞收发失败时怎么加退避而不丢任务

用 select { case ch 做非阻塞发送时，default 只说明这一次发送没有立即就绪，不表示任务已经失败。正确做法是保留待发送任务，记录连续失败次数，再用有上限的退避等待下一次尝试；接收侧同理，读不到数据时不要把“暂时为空”当成“不会再有数据”。

select 的 default 只代表这次没准备好

Go 规范规定，select 会从当前可进行的通信中选择一个；如果没有通信可以进行且存在 default，就选择 default。所以非阻塞尝试的返回值更接近“现在做不了”，而不是“这个任务永远做不了”。

发送和接收要分别看状态：发送进入 default，任务值仍然在发送方手里；接收进入 default，只能说明此刻没有数据。只有接收表达式返回 ok == false，才表示 channel 已关闭且不会再产生新值。

先把失败任务留在本地，再决定何时重试

最容易出错的写法是把任务先从队列取出，发送遇到 default 后直接丢掉。下面的最小模型让 worker 始终持有一个 pending，只有通信成功才把它置空：

type Task struct {
    ID   string
    Body []byte
}

func trySend(out chan

调用方可以把 pending 放在局部变量，也可以放回带容量上限的重试队列。这里的关键不是把 default 改成阻塞发送，而是让“尝试失败”和“任务失败”拥有不同的状态。接收侧若要非阻塞读取，则保留生产者和 channel 的生命周期，下一轮再读即可。

用退避和抖动降低空转

连续命中 default 的循环会占用 CPU；多个 worker 采用同一固定间隔，又可能在同一时刻一起重试。可以按失败次数计算 base * 2^n，再截断到最大等待时间，并加入小范围 jitter：

func backoff(failures int, rnd *rand.Rand) time.Duration {
    const (
        base = 10 * time.Millisecond
        capD = 2 * time.Second
    )
    if failures  8 {
        shift = 8 // 防止移位让等待时间失去可读上限
    }
    delay := base * time.Duration(1 capD {
        delay = capD
    }
    jitter := time.Duration(rnd.Int63n(int64(delay/4) + 1))
    return delay - delay/8 + jitter // 把重试点摊开，仍受 capD 约束
}

func wait(ctx context.Context, d time.Duration) bool {
    timer := time.NewTimer(d)
    defer timer.Stop() // 取消等待时释放仍未触发的计时器
    select {
    case 

time.NewTimer 适合把一个明确的等待点交给 select；每次失败后重新计算等待时长即可。生产代码还应记录失败次数、最近一次尝试时间和队列长度，避免把“退避有效”误判成“下游已经恢复”。抖动不是为了提高吞吐，而是为了避免重试同步。

给取消、关闭和容量设置清晰边界

退避只能解决“暂时发不出去”，不能解决无限积压。队列达到上限时要选择明确策略：阻塞上游、返回可重试错误、落盘，或按业务允许丢弃并记录；不要让一个无界 slice 把内存问题推迟到更晚。

发送方不要在不知道其他发送者状态时主动关闭共享 channel，否则退避中的 worker 可能在下一次发送时触发 panic。更稳妥的约定是由唯一生产者或协调者关闭；接收方通过 value, ok := 区分正常值和关闭信号。所有等待点都应同时监听 ctx.Done()，这样服务停止时不会被退避计时器拖住。

相关问题

select 的 default 会不会丢掉 channel 里的数据？

不会。它只在本次选择没有可进行通信时执行；但如果调用方已经把任务从自己的队列删除，那是业务代码丢了任务。

非阻塞接收为什么不建议一直 for 加 default？

因为没有等待点时会形成忙等。可以改为阻塞接收、定时器唤醒，或在 default 后按失败次数退避。

退避时间是不是越长越好？

不是。它需要结合下游恢复时间、任务时效和队列容量设置上限；长时间任务还应支持取消或转移。

关闭 channel 后还能重试发送吗？

不能。关闭是生命周期终点，不是暂时不可用；发送方必须通过所有权约定避免向已关闭 channel 发送。

把 default 当作瞬时状态，把 pending 当作任务所有权，再把退避、容量和取消分别记录，非阻塞收发就不会靠“不断试”和“默默丢”维持表面运行。