Channel适合轻量单步传递，Dataflow适合可组合多阶段管道；前者开销低但无内置策略，后者支持背压、错误隔离与自动完成传播。
Channel 适合轻量、低开销的生产者-消费者场景
当你的数据流逻辑简单，不需要内置的缓冲策略、链接传播或复杂错误处理时，Channel<t></t> 是更直接的选择。它本质是线程安全的队列封装，开销极低，且与 async/await 天然契合。
常见错误现象：用 Channel 实现多阶段转换时，手动管理多个 Channel 的生命周期和完成信号，容易漏掉 Writer.Complete() 或误判 Reader.Completion.IsCompleted，导致死锁或任务挂起。
实操建议：
- 仅在单步传递（如日志写入、事件广播）或自定义管道中作为底层传输载体使用
- 避免在
Channel<t></t>上做复杂的数据转换——那是TransformBlock<tin tout></tin>的职责 - 若需背压，优先用
Channel.CreateBounded<t>(new BoundedChannelOptions { FullMode = ... })</t>，而非无界通道
TPL Dataflow 更适合可组合、带策略的多阶段处理管道
当你需要把“接收 → 解析 → 验证 → 存储 → 通知”这类流程拆成独立、可复用、可监控的块，并要求自动完成传播、异常隔离、并行度控制或取消传播时，TransformBlock、ActionBlock 等类型比手写 Channel 循环更可靠。
使用场景举例：ETL 流水线、实时指标聚合、命令分发中心——这些都需要块间依赖、失败重试、限流、延迟执行等能力，而 Channel 不提供这些。
实操建议：
- 用
ExecutionDataflowBlockOptions.MaxDegreeOfParallelism控制并发，比手动开Task.Run+Channel更易维护 - 通过
linkTo的propagateCompletion: true自动传递完成状态，减少手工同步逻辑 - 注意
BufferBlock<t></t>默认不启用BoundedCapacity，大量积压时可能 OOM；必要时显式设置
混合使用时的关键边界：何时从 Channel 切换到 Dataflow
一个典型信号是：你开始为 Channel 写包装类，比如 AsyncPipelineStage<tin tout></tin>，并加入重试、超时、熔断、指标上报——这时其实已在重复实现 Dataflow 的功能。
参数差异直接影响决策：
-
Channel<t></t>没有内置错误传播机制；DataflowBlockOptions.TaskScheduler和CancellationToken可统一管控整个块的取消和调度上下文 -
Channel.Reader.ReadAsync()返回单个元素；TransformBlock<tin tout></tin>的委托接收单个输入但可异步返回结果，天然支持 await I/O 操作 -
DataflowBlockOptions.BoundedCapacity作用于块内部缓冲，而Channel的容量控制在创建时绑定，无法运行时调整
性能影响：纯内存搬运场景下，Channel 吞吐略高（约 5–10%），但实际业务中 I/O 或计算耗时远盖过这点差异；Dataflow 的对象分配稍多，但 .NET 6+ 已大幅优化 ITargetBlock 的内存路径。
常见错误：误用 Dataflow 块的完成机制
最常踩的坑是调用 block.Complete() 后，仍向已标记完成的 ITargetBlock 发送数据，触发 InvalidOperationException: "The target block has completed."。这不是 bug，而是设计约束。
正确做法：
- 只对作为管道终点的
ActionBlock或BufferBlock显式调用Complete() - 上游块应通过
linkTo设置propagateCompletion: true，让完成信号自动反向传播 - 若需等待整条管道结束，应
await block.Completion，而不是await Task.WhenAll(...)—— 后者无法感知块内部异常
示例：错误地在 TransformBlock 上调用 Complete() 并继续 Post()：
var transform = new TransformBlock<int, string>(x => x.ToString()); transform.Complete(); // ✅ 标记完成 transform.Post(42); // ❌ 抛出 InvalidOperationException
真正该做的是让源头（比如另一个 BufferBlock）完成，然后 await transform.Completion 等待其处理完所有已入队项。
复杂点在于：Dataflow 的完成传播是“尽力而为”的，如果某块内部抛出未捕获异常，Completion 会以 Faulted 状态结束，且不会自动传播给下游——这点必须手动检查每个块的 Completion 状态，否则管道会静默卡住。
