绝大多数场景下优先用channel.createbounded；因其通过有界缓冲区实现背压，防止内存溢出，而createunbounded仅适用于极轻量短生命周期消息且需严格监控的特殊情况。
Channel.CreateBounded 和 Channel.CreateUnbounded 选哪个？
绝大多数场景下，优先用 Channel.CreateBounded。无界通道（Channel.CreateUnbounded）看似省心，但会无限缓存待处理项，内存可能持续增长直至 OutOfMemoryException——尤其在生产者速度远超消费者时。
有界通道强制背压：当缓冲区满，Writer.WriteAsync 会 await 挂起，自然节制生产节奏。这是 Channel 区别于普通队列的核心价值。
- 缓冲区大小不是拍脑袋定的：设为
1时等效于“同步交接”，适合强顺序/低延迟场景；设为Math.Max(1, Environment.ProcessorCount * 2)是较稳妥的起点 - 若业务能容忍丢弃最老项，可用
new BoundedChannelOptions(capacity) { FullMode = BoundedChannelFullMode.DropOldest } -
Channel.CreateUnbounded仅适用于：消息极轻量、生命周期极短、且你明确监控了Reader.Count和 GC 压力
WriteAsync 不 await 会怎样？
直接调用 channel.Writer.WriteAsync(item) 却不 await，等于把写入任务扔进后台——你无法知道它是否成功、是否被背压阻塞、甚至是否因通道已 Complete() 而抛出 InvalidOperationException。
更危险的是，未 await 的异步操作可能被 GC 提前回收上下文，导致 OperationCanceledException 或静默失败。
- 必须 await：
await channel.Writer.WriteAsync(item); - 若需“尽力发送”且不阻塞当前线程，改用
TryWrite：if (!channel.Writer.TryWrite(item)) { /* 处理写入失败，如日志或降级 */ } - 批量写入用
WriteAsync配合IEnumerable+ChannelWriter<t>.WriteAsync(IEnumerable<t>)</t></t>（.NET 6+），避免循环中反复 await
Consumer 如何安全退出并处理剩余消息？
消费者不能只靠 await foreach (var item in channel.Reader.ReadAllAsync()) 就完事。如果生产者中途调用 channel.Writer.Complete()，该循环会自然退出；但若生产者崩溃或取消，Reader 可能永远等不到“完成信号”，造成线程泄漏。
必须显式控制生命周期，并区分“通道关闭”和“主动取消”。
- 用
CancellationToken包裹读取：await foreach (var item in channel.Reader.ReadAllAsync(ct))，并在外部触发cancellationTokenSource.Cancel() - 退出前检查是否还有未读消息：
while (channel.Reader.TryRead(out var item)) { /* 处理残留 */ } - 务必调用
channel.Writer.Complete()（由生产者调用），否则Reader.Completion永远不会完成，ReadAllAsync的底层Task也不会结束
为什么 ChannelReader.ReadAsync 返回 ValueTask 而不是 Task？
因为 ReadAsync 在缓冲区有数据时可同步返回 true，无需真正 await；只有空且未完成时才需要挂起等待。用 ValueTask 避免高频调用下的 Task 对象分配，对吞吐敏感的场景（如每秒数万消息）能显著降低 GC 压力。
但这意味着你不能把它当作普通 Task 直接 await 后做复杂逻辑——要先判断返回值：
var result = await channel.Reader.ReadAsync(ct);
if (result.HasValue)
{
Process(result.Value);
}
// result.HasValue == false 表示通道已完成且无更多数据
而 ReadAllAsync 内部已封装了这层判断，适合“全量消费”场景；手动用 ReadAsync 则适合需要细粒度控制（如带超时、条件跳过、部分处理后暂停）的情况。
容易忽略的一点：如果你在 ReadAsync 后没消费 result.Value，而是直接丢弃，下次调用仍会返回同一值——Channel 不自动推进读取位置，必须显式读取才能移出缓冲区。
