c# TPL Dataflow ActionBlock 和 TransformBlock 的区别和用法

ActionBlock不能返回值因其设计为只消费不产出的终点，构造函数仅接受Action或Func，无输出泛型参数，故不实现ISourceBlock无法链式输出。

ActionBlock为什么不能返回值？

因为 ActionBlock 的设计定位就是「消费者终点」：它只负责消费数据、执行副作用（比如写日志、发 http 请求、存数据库），不产生新数据。它的构造函数只接受 Action 或 Func，没有输出泛型参数 —— 所以你没法把它直接连到下一个处理块后面。

• 常见错误现象：transformBlock.LinkTo(actionBlock) 没问题，但反过来 actionBlock.LinkTo(...) 会编译失败，提示“ActionBlock 不实现 ISourceBlock”
• 典型使用场景：日志落盘、告警推送、MQ 消息发送、ui 更新（需注意线程上下文）
• 如果你误用 ActionBlock 做转换（比如想把 String 转成 int），编译器不会报错，但逻辑上断链了 —— 后续块收不到任何输出

TransformBlock 怎么正确配置并行和限流？

TransformBlock 是真正能“加工+转发”的核心流水线单元，但它默认是单线程同步执行的。不显式配置，它就退化成一个带队列的普通方法调用，完全浪费了 TPL Dataflow 的价值。

• 必须传入 ExecutionDataflowBlockOptions，否则 MaxDegreeOfParallelism 默认为 1，BoundedCapacity 默认为 Int32.MaxValue（即无界）
• 容易踩的坑：MaxDegreeOfParallelism = DataflowBlockOptions.Unbounded 看似自由，实则可能压垮 I/O 或下游服务；建议设为合理小整数（如 4~16），配合 BoundedCapacity 实现反压
• 异步转换必须用 Func> 构造，不能用同步委托，否则会阻塞线程池线程

var transform = new TransformBlock(     async input =>     {         await Task.Delay(50); // 模拟异步 I/O         return input.ToUpper();     },     new ExecutionDataflowBlockOptions     {         MaxDegreeOfParallelism = 8,         BoundedCapacity = 100     });

什么时候该用 BufferBlock 连接 ActionBlock 和 TransformBlock？

直接 LinkTo 很方便，但一旦下游（比如 ActionBlock）处理变慢，上游（比如 TransformBlock）就会被阻塞 —— 尤其当没设 BoundedCapacity 时，内存可能无限增长。这时候 BufferBlock 就是你的缓冲阀。

• 适用场景：上下游处理速率差异大、需要解耦失败影响（比如日志写入失败不该让解析流程卡死）
• 关键配置：BufferBlock 本身也要设 BoundedCapacity，否则只是把“无界风险”从 A 块转移到 B 块
• 不要滥用：每个额外的 BufferBlock 都增加调度开销和内存占用；仅在真实存在速率差或故障隔离需求时引入

为什么 LinkTo 时加 predicate 却没生效？

LinkTo 的谓词（predicate）不是过滤器开关，而是“是否尝试投递”的条件。如果谓词返回 false，数据会被丢弃（除非你设置了 propagateCompletion = true 并链接了 NullTarget）。

• 常见误解：以为 blockA.LinkTo(blockB, x => x > 0); blockA.LinkTo(blockC, x => x 就能分流 —— 实际上，第一个 LinkTo 返回 false 时，数据不会自动交给第二个，而是直接丢失
• 正确做法：用 LinkTo 的重载传入 new DataflowLinkOptions { PropagateCompletion = false }，再手动调用 blockA.Completion.ContinueWith(...) 处理异常；或者改用 BroadcastBlock + 条件分发
• 调试技巧：给每个块设置 NameFormat（如 new ExecutionDataflowBlockOptions { NameFormat = "Transform-{0}" }），出问题时看日志能快速定位哪个环节丢了数据

TPL Dataflow 的复杂性不在语法，而在“数据生命周期”的显式建模：每个块的状态（completed / faulted）、链接策略（greedy / non-greedy）、容量控制、完成传播——漏掉任意一环，都可能表现为数据静默丢失或内存缓慢泄漏。别依赖“跑起来就行”，先想清楚这条数据从进来到出去，每一步谁负责背锅。