应根据背压需求选择：Bounded用于下游慢时限流防内存爆炸，Unbounded用于吞吐优先且节奏可控场景；选错会导致死锁或OOM而非性能问题。
Channel.CreateBounded 和 Channel.CreateUnbounded 怎么选
选错类型会导致死锁或内存爆炸，不是性能问题而是逻辑崩溃。Bounded 适合背压敏感场景（比如下游处理慢时主动限流），Unbounded 适合吞吐优先、且生产者/消费者节奏可控的场景。
常见错误是默认用 CreateUnbounded 处理高频率日志写入，结果消费者卡住几秒后，内存飙升到 GB 级——因为所有未消费的 ValueTask 都在内部队列里堆着，GC 都救不回来。
- Bounded：设
capacity时必须大于 0，且建议配合FullMode = BoundedChannelFullMode.Wait或DropWrite，否则Writer.TryWrite可能直接返回false而不报错 - Unbounded：没有容量限制，但
Writer.Completion不会因写入失败而完成，出错只能靠外部捕获异常 - 两者都默认不支持多生产者并发写入？错——
Channel本身线程安全，但Writer和Reader实例不是“全局单例”，每个Channel的Writer和Reader是独立对象，可安全跨线程使用
await reader.ReadAsync() 卡住不返回的几种原因
不是 Channel 没数据，而是你没关 Writer 或没处理 Completion。
ReadAsync 在 Channel 关闭且读空后才抛 InvalidOperationException；如果 Writer 还活着、又没新数据，它就一直挂起——这是设计行为，不是 bug。
- 忘记调用
writer.Complete()：尤其在 try/catch 后漏掉 finally 块，导致 reader 永远等不到“结束信号” - Writer 被 GC 掉但没 Complete：.NET 6+ 中
ChannelWriter不实现IDisposable，不会自动 complete，别指望析构器兜底 - 用了
reader.TryRead(out _)循环轮询：这会吃 CPU，且无法感知关闭状态，应改用await ReadAsync+ 捕获OperationCanceledException或检查reader.Completion.IsCompleted
如何安全地从 Channel 读取并处理异常
Channel 本身不传播写入端异常，异常只出现在 Writer.WriteAsync 调用中；但读取端要自己包住处理逻辑，否则一个异常会让整个 consumer 任务退出。
典型反模式是把 await reader.ReadAsync() 和业务处理写在同一 try 块里，结果处理逻辑抛异常后，reader 还在等着下一条，Channel 状态却已混乱。
- 正确做法：用
while (await reader.WaitToReadAsync(ct).ConfigureAwait(false))判断是否还有数据可读，再进if (reader.TryRead(out var item))安全取值 - 业务处理必须包在独立 try/catch 内，且 catch 后不要 return，继续循环——否则中断消费流
- 若需传递异常给下游，得手动写入特殊错误消息，或用
Channel封装，Channel 不负责错误路由>
Channel 与 BlockingCollection 的关键区别在哪
别因为熟悉 BlockingCollection 就迁移到 Channel——它们解决的问题层次不同。
BlockingCollection 是同步阻塞 + 有限线程安全封装，适合简单生产者-消费者模型；Channel 是异步原语，和 async/await 深度绑定，底层用 ValueTask 和无栈协程调度，开销更低，但要求整个调用链支持 async。
- BlockingCollection 支持
GetConsumingEnumerable()，Channel 没有等价物——想同步拉取就得自己 wrap 成IEnumerable，但会丢失 async 优势 - Channel 支持
SingleReader/SingleWriter优化模式（构造时传new UnboundedChannelOptions { SingleReader = true, SingleWriter = true }），此时无锁，性能接近无锁队列；BlockingCollection 没这个选项 - BlockingCollection 可以指定任意
IProducerConsumerCollection（比如ConcurrentQueue或自定义），Channel 固定用内部实现，不可替换
最易被忽略的一点：Channel 的 Reader 和 Writer 是一次性消费模型，不能重复使用同一个 Reader 实例去“重读”历史数据——它不是缓冲区快照，而是流式游标。
