channel更快因其无锁设计、异步原语及零分配优化；blockingcollection依赖锁/cas，高并发下易争用，吞吐低2–5倍且gc更多。
为什么 Channel<t></t> 比 BlockingCollection<t></t> 更快
核心差异在底层机制：BlockingCollection<t></t> 是对 IProducerConsumerCollection<t></t>（如 ConcurrentQueue<t></t>）的线程安全封装，所有操作都依赖锁或 CAS + 自旋；而 Channel<t></t> 是无锁设计，基于 AsyncLocal 和状态机调度，写入/读取路径不共享内存竞争点，尤其在高并发生产消费场景下，避免了锁争用和虚假唤醒开销。
典型表现：100 个生产者 + 100 个消费者压测时，Channel<t></t> 吞吐量常高出 2–5 倍，GC 分配也更少（Channel.CreateBounded<t>()</t> 默认复用内部槽位数组，BlockingCollection 每次 Take 都可能触发等待者队列分配）。
Channel<t></t> 替换 BlockingCollection<t></t> 的关键迁移点
不能直接“替换类名”，二者语义不同：BlockingCollection 是同步阻塞容器，Channel 是异步流抽象。重点改三处：
-
构造方式：用
Channel.CreateBounded<t>(capacity)</t>或Channel.CreateUnbounded<t>()</t>替代new BlockingCollection<t>(new ConcurrentQueue<t>())</t></t> -
写入逻辑：把
collection.Add(item)改为await writer.WriteAsync(item)；注意WriteAsync在满的有界 channel 中会 await，但不会抛异常——而BlockingCollection.Add在满时默认阻塞或抛InvalidOperationException - 读取逻辑：把
collection.Take()改为await reader.ReadAsync()；若需类似TryTake的非阻塞行为，用reader.TryRead(out T item)（同步、不 await）
常见踩坑：关闭、完成与异常处理不对等
BlockingCollection.CompleteAdding() 对应的是 writer.Complete()，但后续调用 WriteAsync 会立即抛 InvalidOperationException；而 reader 不会自动停止——必须靠循环中检测 await reader.WaitToReadAsync() 返回 false（表示 writer 已 complete 且缓冲区为空）。
容易漏掉的关键点：
- 未
await writer.Completion就 dispose channel，可能导致未写出项丢失 - 用
reader.ReadAllAsync()时，如果 writer 未 complete，该方法永不结束；应配合CancellationToken或显式 break -
Channel<t></t>的Reader和Writer可独立 dispose，但一旦writer.Complete()，再Dispose()writer 无副作用；而reader.Dispose()会取消所有挂起的ReadAsync等待，抛OperationCanceledException
性能敏感场景下的参数选择建议
有界 channel 的 SingleWriter / SingleReader 选项能进一步减少内存屏障和状态检查，但仅当业务能保证单生产者/单消费者时才开启——否则运行时行为未定义（不是线程不安全，而是可能跳过某些写入或重复读取）。
推荐配置组合：
- 高吞吐、多生产者 →
Channel.CreateBounded<t>(new BoundedChannelOptions(capacity) { FullMode = BoundedChannelFullMode.Wait })</t> - 低延迟、允许少量丢弃 →
FullMode = BoundedChannelFullMode.DropWrite（写满时直接丢弃新项，不 await） - 需要精确控制背压 → 配合
Channel.Reader.Count和Channel.Writer.TryWrite做主动节流，而非全靠 await
真正难调的不是 API 用法，而是把「同步阻塞思维」切换成「异步流+完成信号」模型——比如原来靠 BlockingCollection.IsAddingCompleted 判断是否退出循环，现在得监听 reader.Completion 并处理 WaitToReadAsync().IsCompleted 的边界条件。
