Channel.CreateBounded卡死或抛OperationCanceledException的根本原因是未启动消费者任务，导致写入时缓冲区满而阻塞或取消；必须显式启动长期运行的Reader.ReadAsync循环，并合理配置BoundedChannelOptions。
Channel.CreateBounded 为什么一用就卡死或抛 OperationCanceledException
根本原因不是代码写错了，而是没启动消费端——Channel 默认不自动拉取，写入后没人 Reader.ReadAsync()，缓冲区满就会阻塞（同步模式）或抛 OperationCanceledException（异步限流模式）。这和 BlockingCollection 的“自动等待”直觉相反。
实操建议：
- 必须显式启动至少一个长期运行的消费者任务，调用
await channel.Reader.ReadAsync(cancellationToken)循环读取 - 不要在 UI 线程或短生命周期作用域（如 ASP.NET Core 中间件单次请求）里直接
WriteAsync后就结束——写入可能永远挂起 - 创建时显式传入
BoundedChannelOptions，避免依赖默认值：var channel = Channel.CreateBounded<int>(new BoundedChannelOptions(100) { FullMode = BoundedChannelFullMode.Wait }); -
FullMode = BoundedChannelFullMode.DropWrite可丢弃新写入项，适合日志、监控等容忍丢失的场景；但别在金融类流程里用
WriteAsync 阻塞 vs TryWrite 的区别和选型依据
WriteAsync 在有界通道满时会 await，直到有空位或超时/取消；TryWrite 立即返回 bool，不等待。这不是性能高低问题，而是语义差异：你要的是「背压控制」还是「尽力而为」。
常见错误现象：用 TryWrite 替代 WriteAsync 却没处理 false 返回值，导致数据静默丢失。
使用场景建议：
- 需要精确控速、防止下游过载（如批量处理外部 API 调用）→ 用
WriteAsync+ 合理FullMode - 高频埋点、指标上报，可容忍少量丢失 →
TryWrite，但必须检查返回值：if (!channel.Writer.TryWrite(item)) { /* 记录丢弃日志或降级处理 */ } -
TryWrite不受cancellationToken影响，无法响应取消；WriteAsync支持 cancellation，适合长时管道
如何安全关闭 Channel 并确保所有数据被消费完
调用 Writer.Complete() 只是标记“不再写入”，不会自动停止读取；如果消费者还在 ReadAsync，它会收到 ChannelClosedException 或读到 default(T)（取决于是否检查 WaitToReadAsync），但更常见的是漏掉最后一批数据。
关键点在于：关闭 ≠ 消费完成。必须等 Reader.Completion 完成才算真正收尾。
实操建议：
- 写入方完成前调用
channel.Writer.Complete() - 消费者循环中需配合
await channel.Reader.WaitToReadAsync()判断是否还有数据可读：while (await channel.Reader.WaitToReadAsync(ct)) { if (channel.Reader.TryRead(out var item)) { /* 处理 */ } } - 最终用
await channel.Reader.Completion等待消费者自然退出，而不是直接await channel.Writer.Completion - 若消费者任务已
Task.Run启动，记得用async Task包裹，并传播cancellationToken防止僵尸任务
和 Channel.CreateUnbounded 对比：什么时候不该用 BoundedChannel
CreateUnbounded 看似简单，但本质是无内存保护的队列——生产快、消费慢时，内存持续上涨，OOM 风险极高。BoundedChannel 的价值不在“限制大小”，而在把压力暴露出来，逼你做决策。
容易踩的坑：
- 把
BoundedChannelOptions的Capacity设得过大（比如 100000），等于变相 Unbounded，失去限流意义 - 在高吞吐低延迟场景（如实时音视频帧传递）用 BoundedChannel，频繁阻塞反而增加延迟抖动——这时该考虑
MemoryPool+ 手动 ring buffer - ASP.NET Core 中直接在
ControllerAction 里WriteAsync到全局Channel，但没配好IServiceProvider生命周期，导致Channel被提前 GC 或跨请求污染 - 想替代
ConcurrentQueue做纯线程安全缓存？别用Channel——它设计目标是异步流控，不是随机访问或 Peek
边界感要清楚：BoundedChannel 是“带背压的异步队列”，不是万能线程安全容器。容量设多少，得看你的消费速率、容忍延迟、内存预算三者平衡——没有银弹值，只有压测出来的数字。
