Channel天然支持MPMC，因其底层基于无锁队列和AsyncOperation状态机，依赖内存屏障与CAS实现线程安全，无需手动加锁；但Writer.Complete()不可并发调用，有界通道容量不当易致死锁，ReadAllAsync()仅限单消费者使用。
ChannelChannel.CreateUnbounded 或 Channel.CreateBounded 显式创建，不能直接 new。
为什么 Channel 天然支持多生产者多消费者
ChannelAsyncOperation 状态机，所有 Writer.WriteAsync() 和 Reader.ReadAsync() 调用都通过内部的并发安全状态流转完成。它不依赖 Monitor 或 Semaphore，而是靠内存屏障 + CAS 操作保障线程安全。
常见误解是“要手动加锁才能多写”，其实只要每个生产者持有同一个 ChannelWriter 实例、每个消费者持有同一个 ChannelReader 实例，就天然满足 MPMC —— 无需额外同步代码。
- 多个线程调用
channel.Writer.WriteAsync(item)是安全的 - 多个线程调用
channel.Reader.ReadAsync()也是安全的 - 但
channel.Writer本身不可被多个线程同时Complete()，否则抛InvalidOperationException -
channel.Reader可被任意线程调用WaitToReadAsync()，无限制
Channel.CreateBounded 容量设置不当会死锁
使用有界通道时，如果生产者写入速度持续高于消费者读取速度，WriteAsync() 会 await 挂起，直到有空位；但若所有消费者都阻塞在其他逻辑上（比如等 I/O），而生产者又全部卡在 WriteAsync()，就会形成分布式等待死锁 —— 表现为程序“卡住”，CPU 低，无异常。
- 默认
Channel.CreateBounded的缓冲区满后，后续(100) WriteAsync()返回未完成的Task - 若用
await writer.WriteAsync(item)且无超时，就可能永远挂起 - 推荐搭配
TimeSpan重载：await writer.WriteAsync(item, cancellationToken)，并传入带超时的CancellationToken - 更稳妥的做法是用
TryWrite()做非阻塞写入，失败时走降级逻辑（如丢弃、告警、写日志）
ChannelReader.ReadAllAsync() 不适合多消费者场景
ChannelReader 返回一个 IAsyncEnumerable，但它内部只允许**一个消费者枚举**。如果两个线程同时 foreach 同一个 ReadAllAsync() 结果，第二个会立刻抛 InvalidOperationException: "Collection was modified; enumeration operation may not execute."。
- 正确做法：每个消费者单独调用
reader.ReadAsync()，自己处理循环 - 错误写法：
await foreach (var x in channel.Reader.ReadAllAsync()) { ... }×（仅限单消费者） - 正确写法：
while (await reader.WaitToReadAsync()) while (reader.TryRead(out var item)) { ... }✓ - 注意
WaitToReadAsync()返回ValueTask，比ReadAsync()更轻量，适合高频轮询
关闭通道时 Writer.Complete() 的调用时机很关键
ChannelWriter 表示“不再写入”，但它**不阻塞**，也不等待已提交的写入完成。如果在调用 Complete() 后立即 dispose channel，而此时还有未完成的 WriteAsync()，会触发 ObjectDisposedException。
- 务必确保所有生产者已完成写入，或用
await writer.Completion等待所有 pending 写入结束 - 典型模式：
await Task.WhenAll(producers); writer.Complete(); await writer.Completion; - 消费者端检测关闭：当
ReadAsync()返回default(T)且reader.Completion.IsCompleted为 true，说明通道已关闭且无更多数据 - 别依赖
reader.Completion.Exception判断是否出错——正常关闭时它也是 null
真正容易被忽略的是：Channel 的生命周期管理必须和业务语义对齐。比如一个 HTTP 请求对应一个 Channel，那它的 Writer 就该由请求处理逻辑控制关闭，而不是由某个后台线程随意 Complete。错配会导致消费者永远等不到 “结束信号”，或收到意外中断。
