BackgroundService 的 ExecuteAsync 必须持续 await 读取 Channel，否则只执行一次；应使用 Bounded Channel 配合背压控制，任务需 try/catch 处理异常并指数退避重试，避免未完成 Task 或漏传 CancellationToken 导致静默失败。
BackgroundService 启动后不执行 ExecuteAsync？
常见现象是服务注册了，但队列任务始终没被消费——根本原因是 BackgroundService.StartAsync 被调用后，ExecuteAsync 只会运行一次（除非你手动循环）。它不是“持续运行的线程”，而是靠你返回一个未完成的 Task 来维持生命周期。
- 必须在
ExecuteAsync中用await channel.Reader.ReadAsync(cancellationToken)或await foreach持续读取，不能只读一次就 return - 如果用了
while (!stoppingToken.IsCancellationRequested)却忘了 await 读操作，会导致 CPU 空转或假死 - .NET 6+ 推荐用
await foreach (var job in channel.Reader.ReadAllAsync(cancellationToken))，自动处理完成与取消
Channel 的 SingleWriter 和 MultiWriter 怎么选？
SingleWriter 和 MultiWriter 怎么选？这直接决定你能否从多个地方（比如 HTTP Controller、gRPC 方法、定时器）安全地往队列里投递任务。默认 Channel.CreateUnbounded<t>()</t> 是 MultiWriter，但性能略低；SingleWriter 更快，但只允许一个写入者。
- 绝大多数 Web 场景要用
Channel.CreateBounded<t>(new BoundedChannelOptions(100) { SingleReader = true, SingleWriter = false })</t> -
SingleWriter = false才支持从不同 Controller Action 并发调用channel.Writer.TryWrite(job) - 别用
Unbounded做生产环境队列——内存可能无限增长，OOM 风险高；Bounded配合await channel.Writer.WaitToWriteAsync()才可控
任务失败后怎么重试 + 降级？
Channel 本身不提供重试逻辑，BackgroundService 也不捕获消费者异常——一旦 ExecuteAsync 内抛出未处理异常，服务会直接停止，后续任务全部丢失。
- 必须把每个 job 的执行包在
try/catch里，且 catch 后记录日志，**不能 throw 出去** - 重试建议用
ExponentialBackoff：第一次等 1s，第二次 2s，第三次 4s……避免雪崩 - 重试次数上限建议设为 3～5 次，超限后写入死信队列（比如本地文件或数据库表），别丢弃
- 示例关键行：
await Task.Delay(TimeSpan.FromSeconds(Math.Pow(2, retryCount)), cancellationToken)
为什么 ChannelReader.ReadAllAsync 有时卡住不返回？
这不是 bug，是 Channel 的设计特性：ReadAllAsync 只有在 writer 调用 Complete() 后才结束枚举。而 BackgroundService 生命周期通常和应用一致，writer 永远不会 complete —— 所以它本就不该“结束”，卡住反而是正常表现。
- 真正的问题是：你是否误用了
ReadAllAsync在非流式场景？比如想“取一批任务处理完再继续”，那就该用WaitToReadAsync + TryRead循环 - 如果坚持用
await foreach，确保 reader 不会因 writer 关闭而意外退出（例如在StopAsync里调了channel.Writer.Complete()，但 reader 还在跑） - 调试时可在循环开头加
if (cancellationToken.IsCancellationRequested) break;，防止停机时 hang 住
WaitToWriteAsync）和 BackgroundService 的取消传播（cancellationToken 传入每一层 await）——漏掉任一环节，队列就可能在高并发下失序、堆积或静默失败。 
