Go select 发送到满 channel 时怎么设计退避与丢弃策略

做一个异步事件队列时，最容易出现的误判是：channel 满了，就在 select 外层加一个死循环不断重试。这样虽然消息可能最终发出去，但发送方会在消费者变慢时持续占用 CPU。更稳妥的做法是把“是否允许等待”写进策略：普通事件用 default 立即丢弃并计数，可恢复事件做有限次退避，绝不能丢的事件才交给带超时的阻塞发送。

满 channel 时，select { case ch 只表示这一次不能立即发送；它不是重试机制。退避要有上限，丢弃要按事件价值决定，关闭则必须由生产者与消费者共同约定。

为什么满 channel 时 default 会立即接管

Go 规范把 send case 是否可继续交给通信状态判断：无缓冲 channel 需要接收方准备好，有缓冲 channel 需要仍有空位。如果所有通信都不能立即进行，又存在 default，本次 select 就直接执行默认分支；没有 default 才会等待。

func tryEnqueue(ch chan

这个写法很适合日志采样、指标快照等“丢一条仍可继续”的事件。要注意两个边界：向已关闭的 channel 发送仍会 panic；向 nil channel 发送永远不会就绪，但这里有 default，因此会立即返回 false。关闭协议不能靠丢弃分支猜测。

用有限退避替代紧密轮询

如果事件暂时不能丢，可以在第一次快速尝试失败后短暂等待，再用指数退避重试。等待必须可取消，否则消费者退出后，生产者可能一直留在发送路径里。下面的函数最多尝试 5 次，延迟从 2 毫秒增长到 100 毫秒，并由 context 负责刹车。

func enqueueWithBackoff(ctx context.Context, ch chan maxDelay { delay = maxDelay }
        }
    }
    return false // 达到等待预算后交给上层决定如何记录
}

这段代码只解决“暂时拥堵”。它不会修复永远没有消费者的 channel，也不会让关闭后的 channel 变得可发送。生产环境还应把退避失败次数、等待总时长和队列当前长度做成指标，避免把“消息没丢”误认为“系统健康”。

退避和丢弃策略要跟业务价值绑定

不要给所有事件统一配置重试次数。事件能否从数据库或缓存重建，通常比它的名字更适合作为判断依据。一个小型遥测队列可以采用下面的决策表：

“丢弃”不等于静默吞掉。发送器至少要返回成功/失败，并由调用方增加计数；如果事件有 key，可以用“最新值覆盖”代替无限堆积。关键事件不适合只放在内存 channel 中，进程崩溃、取消或消费者异常时仍需要外部持久化和补偿机制。

用关闭协议和指标验收方案

发送端不要在多个 goroutine 中随意关闭共享 channel。通常由创建并拥有发送权的一方负责关闭，消费者通过 range ch 读到结束；如果发送器仍可能运行，就先停止生产、等待发送 goroutine 退出，再关闭 channel。这样才能从根上避免“满了就丢”和“已经关闭”被混为一谈。

验收时至少观察四件事：队列满时 CPU 没有持续打满；drop_total 与业务预期相符；取消后退避函数能返回；关闭后没有新的发送者。若必须保证关键事件不丢，测试应故意让消费者暂停，确认超时、补偿和告警路径都能留下记录。

常见问题

把 default 删除是不是就能避免丢消息？

删除后会等待发送完成，但可能把请求处理 goroutine 一起拖住。只有调用方明确允许阻塞，并且有 context 超时，才适合这样做。

能不能在 default 里马上再执行一次 select？

不建议。没有延迟的循环就是忙等；应使用 Timer、有限次数和取消信号，或者把事件交给具备持久化能力的队列。

channel 容量调大后还需要丢弃指标吗？

需要。容量只是吸收突发，不会改变消费者长期吞吐。没有计数就无法知道容量是否只是把故障推迟。

最终的判断顺序可以很简单：先问事件能不能丢，再问调用方能等多久，最后才决定 channel 容量和退避参数。这样 select 的 default 才是明确的过载策略，而不是隐藏的失败分支。