ActionBlock 为什么不能返回值？
因为
ActionBlock<t></t>的设计定位就是「消费者终点」：它只负责消费数据、执行副作用（比如写日志、发 HTTP 请求、存数据库），不产生新数据。它的构造函数只接受
Action<t></t>或
Func<t task></t>，没有输出泛型参数 —— 所以你没法把它直接连到下一个处理块后面。 常见错误现象：
transformBlock.LinkTo(actionBlock)没问题，但反过来
actionBlock.LinkTo(...)会编译失败，提示“
ActionBlock<t></t>不实现
ISourceBlock<u></u>” 典型使用场景：日志落盘、告警推送、MQ 消息发送、UI 更新（需注意线程上下文） 如果你误用
ActionBlock做转换（比如想把
string转成
int），编译器不会报错，但逻辑上断链了 —— 后续块收不到任何输出
TransformBlock 怎么正确配置并行和限流？
TransformBlock是真正能“加工+转发”的核心流水线单元，但它默认是单线程同步执行的。不显式配置，它就退化成一个带队列的普通方法调用，完全浪费了 TPL Dataflow 的价值。 必须传入
ExecutionDataflowBlockOptions，否则
MaxDegreeOfParallelism默认为 1，
BoundedCapacity默认为
Int32.MaxValue（即无界） 容易踩的坑：
MaxDegreeOfParallelism = DataflowBlockOptions.Unbounded看似自由，实则可能压垮 I/O 或下游服务；建议设为合理小整数（如 4~16），配合
BoundedCapacity实现反压 异步转换必须用
Func<tinput task>></tinput>构造，不能用同步委托，否则会阻塞线程池线程
var transform = new TransformBlock<string, string>(
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<t></t>就是你的缓冲阀。 适用场景：上下游处理速率差异大、需要解耦失败影响（比如日志写入失败不该让解析流程卡死） 关键配置：
BufferBlock本身也要设
BoundedCapacity，否则只是把“无界风险”从 A 块转移到 B 块 不要滥用：每个额外的
BufferBlock都增加调度开销和内存占用；仅在真实存在速率差或故障隔离需求时引入
为什么 LinkTo 时加 predicate 却没生效？
LinkTo的谓词（predicate）不是过滤器开关，而是“是否尝试投递”的条件。如果谓词返回
false，数据会被丢弃（除非你设置了
propagateCompletion = true并链接了
NullTarget）。 常见误解：以为
blockA.LinkTo(blockB, x => x > 0); blockA.LinkTo(blockC, x => x 就能分流 —— 实际上，第一个 <code>LinkTo返回
false时，数据不会自动交给第二个，而是直接丢失 正确做法：用
LinkTo的重载传入
new DataflowLinkOptions { PropagateCompletion = false }，再手动调用 blockA.Completion.ContinueWith(...)处理异常；或者改用
BroadcastBlock<t></t>+ 条件分发 调试技巧：给每个块设置
NameFormat（如
new ExecutionDataflowBlockOptions { NameFormat = "Transform-{0}" }），出问题时看日志能快速定位哪个环节丢了数据
TPL Dataflow 的复杂性不在语法，而在“数据生命周期”的显式建模：每个块的状态（completed / faulted）、链接策略（greedy / non-greedy）、容量控制、完成传播——漏掉任意一环，都可能表现为数据静默丢失或内存缓慢泄漏。别依赖“跑起来就行”，先想清楚这条数据从进来到出去，每一步谁负责背锅。 
