选通道类型需依场景：实时丢弃旧任务用有界+DropWrite；保序不丢数据用有界+合理容量；消息稀疏难预估峰值用无界但监控Count。
Channel.CreateBounded 和 Channel.CreateUnbounded 怎么选
选错通道类型是阻塞、丢数据或内存暴涨的常见源头。有界通道（Channel.CreateBounded<t></t>）会限制内部队列长度，写入时若缓冲区满，默认行为是 await 阻塞；无界通道（Channel.CreateUnbounded<t></t>）用 ConcurrentQueue<t></t> 底层实现，写入永不阻塞，但可能吃光内存。
实际选型看场景：
- 实时性要求高、能容忍偶尔丢弃旧任务（如传感器采样流）→ 用有界 +
WriteAsync配合CancellationToken超时，或启用FullMode = BoundedChannelFullMode.DropWrite - 必须保序、不丢数据、生产速率稳定（如订单入库队列）→ 有界 + 合理容量（比如 1000），靠背压让上游降速
- 消息稀疏、无法预估峰值、且内存可控（如后台作业调度器）→ 无界更省心，但务必监控
Channel.Reader.Count防堆积
Producer 写入时为什么 Channel.Writer.TryWrite 返回 false
TryWrite 只在有界通道已满且 FullMode 设为 DropWrite 或 DropLatest 时才可能返回 false；默认 Wait 模式下它根本不会返回 false——而是直接 throw InvalidOperationException：“Channel is closed” 或 “Writer is completed”。真正容易误判的是：你以为在写，其实 Writer 已被 Complete() 或异常终结。
安全写法要同时检查两个状态：
if (!channel.Writer.TryWrite(item))
{
// 仅当 FullMode != Wait 时才进这里
Console.WriteLine("Dropped due to full channel");
}
else if (channel.Writer.Completion.IsFaulted)
{
// Writer 已出错，后续写入都无效
await channel.Writer.Completion; // 触发异常
}
Consumer 用 Channel.Reader.ReadAsync 还是 TryRead
ReadAsync 是核心推荐方式，它天然支持异步等待、取消和背压传递；TryRead 是同步非阻塞，只适合“看看有没有现成数据，没有就算了”的轮询场景（比如 UI 心跳检测），滥用会导致 CPU 空转。
典型消费者循环应这样写：
await foreach (var item in channel.Reader.ReadAllAsync(ct))
{
await ProcessAsync(item);
}
注意三点：
-
ReadAllAsync自动处理Writer.Complete()后的退出，无需手动while (await Reader.WaitToReadAsync()) -
ct（CancellationToken）必须传入，否则ReadAllAsync在 Writer 关闭前无法响应取消请求 - 若
ProcessAsync抛异常，ReadAllAsync会终止迭代，但Reader.Completion不会自动标记失败——需自行try/catch并调用channel.Writer.TryComplete(ex)通知上游
Channel 与 BlockingCollection 的关键差异在哪
别因为习惯用 BlockingCollection<t></t> 就默认它更适合生产者消费者——两者设计目标不同：BlockingCollection 是线程安全的“容器”，侧重同步阻塞操作；Channel 是异步数据流管道，天然支持 async/await、取消传播、多 reader/writer 共享。
迁移时最常踩的坑：
-
BlockingCollection的GetConsumingEnumerable()是同步枚举器，不能await，强行套Task.Run包裹会丢失上下文、增加线程开销 -
Channel.Reader的Count是快照值，可能刚读完就变；而BlockingCollection.Count是锁保护的实时值，但代价是每次访问都加锁 -
Channel支持SingleReader/SingleWriter优化模式，此时底层跳过并发队列，性能接近数组——但BlockingCollection没这个选项
如果代码里还混着 Monitor.Enter、AutoResetEvent 或手写的 ConcurrentQueue + 循环 TryDequeue，说明你还没真正释放 Channel 的异步流能力。
