应根据背压需求选择通道类型：背压敏感场景用有界通道（如实时日志），避免内存爆炸；数据量小且消费及时可用无界通道，但需配超时或取消检查。
Channel.CreateBounded 和 Channel.CreateUnbounded 怎么选
选错类型会导致死锁或内存爆炸，不是性能问题而是逻辑崩溃。
有界通道 Channel.CreateBounded<T>(capacity) 在写入时可能阻塞（当缓冲区满），适合背压敏感场景，比如实时日志采集、下游处理速度不稳定；无界通道 Channel.CreateUnbounded<T>() 写入永不阻塞，但若生产者远快于消费者，内存会持续增长，最终 OutOfMemoryException。
- 下游处理耗时波动大 → 用有界通道 + 合理
capacity（比如 100～1000，别设 1 或 int.MaxValue） - 数据量小、生命周期短、且能确保消费及时 → 可用无界，但必须配超时或取消检查
- 测试时用无界容易掩盖背压问题，上线前务必切回有界并压测
WriteAsync 和 TryWrite 的区别和使用时机
TryWrite 是同步非阻塞，写不进就立刻返回 false；WriteAsync 是异步，会在缓冲区满时等待（有界通道）或直接完成（无界通道）。别以为“Async 就一定快”——它只是把阻塞转成 await 挂起。
- 你控制生产节奏（比如轮询传感器），想丢弃旧数据保实时性 → 用
TryWrite，失败就continue或Log.Warning - 必须确保每条数据都送达（如订单事件），且能接受延迟 → 用
WriteAsync，但要加CancellationToken防卡死 -
WriteAsync在有界通道中可能抛OperationCanceledException，不是 bug，是正常背压响应
Consumer 如何安全读取并避免 ChannelReader.ReadAllAsync 的坑
ChannelReader.ReadAllAsync 看似方便，但它会一直读到 Channel 被 Complete，而很多人忘了手动调用 channel.Writer.Complete()，结果 await foreach 永不退出，任务悬停。
- 明确谁负责关闭：通常是生产者结束时调用
channel.Writer.Complete()，不要依赖 GC 或作用域结束 - 消费者侧别只写
await foreach (var item in reader.ReadAllAsync())，加个break条件或超时保护更稳妥 - 如果消费者可能提前退出（比如用户取消），要用
reader.Completion监听异常，并处理channel.Reader.TryRead(out _)清空残留 - 别在
ReadAllAsync循环里做耗时 IO，否则会堵住整个 reader —— 用Task.Run或管道后置处理
多消费者共享一个 ChannelReader 会怎样
可以，但必须注意：所有消费者共用同一个 ChannelReader<T> 实例，不是每个消费者 new 一个。误操作会导致部分数据被跳过或重复读取。
-
channel.Reader是线程安全的，多个Task并发WaitToReadAsync+TryRead没问题 - 但不能对同一
ChannelReader同时启动多个ReadAllAsync，它们会争抢数据，行为未定义 - 需要扇出（fan-out）时，应让每个消费者从同一个
reader读，而不是 clone 或复制 reader - 如果真要隔离语义（比如不同优先级消费者），得用多个独立 channel，或者上层加路由逻辑
Complete，消费者卡在 ReadAllAsync；还有就是有界通道容量设成 1 却期望高吞吐，结果全程阻塞。这些不是代码写错了，是模型理解偏了。 
