Channel不是万能队列替代品，用错类型或忽略Complete()会导致死锁、内存泄漏或消费者永远等不到结束信号；有界通道才是高吞吐默认选择，需依峰值设容量并显式配置FullMode，SingleWriter/Reader优化性能，Complete()必须且仅调用一次，消费者应避免await foreach隐式陷阱而用手动循环，多消费者共享Reader是竞争消费非广播。
Channel 不是万能队列替代品，用错类型或忽略 Complete() 会导致死锁、内存泄漏或消费者永远等不到结束信号。
什么时候该用 Channel.CreateBounded 而不是 CreateUnbounded
无界通道看似省事，但实际生产环境里它常是性能隐患的源头：内存不受控增长、GC 压力陡增、OOM 风险升高。有界通道才是高吞吐场景的默认选择。
- 明确知道峰值消息量（比如每秒最多 500 条，处理延迟 ≤200ms），就设容量为
500 * 2左右，留出缓冲余量 - 用
BoundedChannelOptions显式配置FullMode，别依赖默认的Wait—— 若生产者卡住，整个流水线会挂起 - 对实时性敏感的场景（如 PLC 数据采集），选
DropOldest：宁可丢旧数据，也不能让新数据堵在门口 -
SingleWriter = true和SingleReader = true能显著降低内部同步开销，多线程写入时才需设为false
channel.Writer.Complete() 必须调用，且只能调用一次
这是最容易被忽略的致命点。不调用，ReadAllAsync() 永远不会退出；重复调用，抛 InvalidOperationException：“The writer has already been completed.”
- 只在**确定不再有新消息产生**时调用，比如生产任务自然结束、收到终止信号、或超时强制关闭
- 多个生产者共用一个
Writer时，不能各自Complete()，得用ChannelWriter<t>.TryComplete()</t>或外层加计数协调 - 若用
WaitToReadAsync()+TryRead()手动循环，Complete()后WaitToReadAsync()会立刻返回false，这是判断“流已终结”的唯一可靠依据
消费者端避免 await foreach 的隐式陷阱
await foreach (var item in reader.ReadAllAsync()) 看起来简洁，但它会一直等待，直到 Writer.Complete() 被调用。如果生产者出错没调用 Complete()，这个循环就卡死了，且无法用 CancellationToken 中断。
- 需要超时控制或可取消逻辑时，改用手动循环：
while (await reader.WaitToReadAsync(token)) { while (reader.TryRead(out var item)) { ... } } -
ReadAllAsync()内部不响应CancellationToken的取消请求，token 只作用于等待新消息阶段，不影响已读出的迭代 - 批量读取更高效：用
reader.ReadManyAsync(buffer, token)一次性取多条，减少 async 状态机切换开销
多消费者共享一个 Reader 时的实际行为
ChannelReader<t></t> 本身不是“广播器”。多个消费者调用 ReadAllAsync()，消息会被**竞争消费**——谁先拿到谁处理，不是每人都分一份。
- 真要实现广播（如日志分发到监控+存储+告警），得用多个独立
Channel，或上System.Threading.Tasks.Dataflow的BroadcastBlock - 若想负载均衡，直接启动多个消费者任务，共用同一个
Reader即可，Channel 内部已做并发安全调度 - 注意：
Reader不持有引用计数，任意消费者调用Complete()（虽然不该这么干）会影响所有其他消费者
最复杂的点不在 API 调用，而在于「谁负责标记完成」和「边界策略如何匹配业务语义」——这两个决策一旦定错，调试时往往表现为消费者静默退出、内存缓慢上涨或偶发超时，很难直接关联到 Channel 配置上。
