Channel 不是 BlockingCollection 的异步平替，关键在容量控制、Complete 时机和 CancellationToken 传递；1000 是兼顾背压与内存安全的典型起始容量，需按数据大小重算；必须显式配置 BoundedChannelOptions，禁用 DropOldest；读写两端均需传递 CancellationToken；Complete() 仅由生产者调用且只能一次；大文件处理须用 ArrayPool 避免脏数据或 OOM。
Channel 不是 BlockingCollection 的异步平替，用错就卡死或内存爆掉——关键在容量控制、Complete 时机和 CancellationToken 传递。
为什么 Channel.CreateBounded(1000) 是多数场景的起点
容量不是随便拍的数字。设成 10：生产者频繁 await 在 WriteAsync 上，消费者稍慢一点整条流水线就堵住；设成 100000：单次读取日志文件时，若消费者异常退出没调 Complete()，缓冲区持续堆积，OutOfMemoryException 很快出现。
1000 这个值来自典型文本行长度（约 100–200 字节）× 预估并发批次（5–10 行），兼顾背压可见性和内存安全。若处理的是 JSON 对象或二进制块，按单条平均大小重算：capacity = (expected_avg_size_bytes * batch_count) / sizeof(byte)，但别直接套用字节数——Channel<byte></byte> 本身不拷贝数组，得自己管理 buffer 生命周期。
- 永远显式传
BoundedChannelOptions，别依赖默认构造函数 -
FullMode = BoundedChannelFullMode.Wait是唯一安全选项；DropOldest等模式会静默丢数据，调试时极难定位 - 无界通道（
CreateUnbounded）只适用于短生命周期任务（如单次 HTTP 请求处理），且必须配超时逻辑
await foreach (var x in reader.ReadAllAsync(ct)) 里的 ct 到底要不要传
要。不传 CancellationToken，Ctrl+C 或服务关闭时，ReadAllAsync 会卡在等待新数据上，无法响应取消信号。常见错误是只在 WriteAsync 里传了 token，却忘了读端。
更隐蔽的问题：如果消费者提前退出（比如解析失败），但没调 channel.Writer.Complete(Exception)，生产者还在写，Channel 内部状态就变成“可写但无人读”，后续所有 WriteAsync 都会无限等待——除非你设了 FullMode = DropWrite，但那是掩盖问题，不是解决问题。
- 生产者写入时：用
await writer.WriteAsync(item, ct) - 消费者读取时：用
await foreach (var item in reader.ReadAllAsync(ct)) - 主动终止时：调
writer.Complete(new OperationCanceledException())，让 reader 尽快收到 Completion 异常
Channel 处理大文件分块时的内存雷区
直接 new byte[8192] 在循环里反复分配，GC 压力陡增；更危险的是复用同一块 byte[] 实例并多次 WriteAsync——Channel 不做深拷贝，后一次写入会覆盖前一次内容，消费者读到的就是脏数据。
正确做法是配合 ArrayPool<byte>.Shared</byte> 租借/归还 buffer，或改用 Channel<readonlymemory>></readonlymemory> + MemoryOwner<byte></byte> 管理生命周期。但注意：.NET 6+ 中 Channel<memory>></memory> 仍不安全，因 Memory<t></t> 可能引用栈内存。
- 避免
new byte[bufferSize]，改用ArrayPool<byte>.Shared.Rent(bufferSize)</byte> - 写入后立刻
ArrayPool<byte>.Shared.Return(buffer)</byte>，别等 GC - 若必须用
byte[]，每次WriteAsync前Array.Copy到新数组（性能换安全） - 二进制场景优先考虑
Channel<readonlysequence>></readonlysequence>，配合PipeReader流式处理
Complete() 调用时机不对，整个管道就僵住
Complete() 必须由生产者调用，且只能调一次。常见错误是在生产者还没写完时就调了，或者在异常分支里漏掉。消费者不能调 Complete()，它只负责读；也不该在 ReadAllAsync 循环里手动 break 后调 Complete()——那属于生产者职责。
另一个坑：多个生产者共用一个 Writer 时，必须确保所有生产者都完成写入后再调 Complete()。没有内置的“多生产者完成协调”机制，得靠 Task.WhenAll 或计数器手动同步。
- 单生产者：在
for或while循环结束后立即调writer.Complete() - 多生产者：用
CountdownEvent或TaskCompletionSource协调，全部就绪再Complete() - 异常路径：所有
try/catch分支都要确保Complete()被调用，哪怕传ex
最易被忽略的一点：Channel 的 Reader 和 Writer 是分离对象，但共享底层队列状态。一旦 Writer.Complete()，Reader 的 WaitToReadAsync() 最终会返回 false，但已进入 ReadAllAsync() 循环的迭代不会中断——它会读完剩余数据才退出。所以，Complete 的位置决定了消费者能看到多少“尾部数据”，这在实时性要求高的场景里，就是延迟的来源。
