tpl dataflow 是用于构建多阶段异步流水线的进程内工具，支持背压控制、独立调优与可链接管道；它不替代线程池，也不单纯用于写异步逻辑。
直接说结论：TPL Dataflow 不是用来“替代线程池”或“写异步逻辑”的，它是用来把多阶段、异步、有节奏差异的处理逻辑，组织成可链接、可背压、可独立调优的进程内流水线。你如果正在写 Parallel.ForEachAsync + 手动 ConcurrentQueue + Task.Run 套娃，那大概率该换用 Dataflow。
什么时候该用 BufferBlock<t></t> 而不是 TransformBlock<tinput toutput></tinput>
当你的“中间环节”只做暂存和转发，不涉及任何计算、类型转换或异步等待时，BufferBlock<t></t> 是更轻量的选择。它没有委托调用开销，不触发调度，纯内存队列，吞吐更高。
- 常见误用：用
TransformBlock<int int>(x => x)</int>当缓冲区，结果 CPU 没怎么跑，线程却频繁唤醒 —— 因为每次Post都会触发委托调度 - 正确做法：用
BufferBlock<int></int>接收数据，再配合ReceiveAsync循环 + 计数器或Timer实现批量拉取（例如攒够 100 条或 500ms 后统一处理） -
BufferBlock适合解耦生产/消费节奏；TransformBlock必须有实际转换逻辑才体现价值，否则是冗余抽象
ExecutionDataflowBlockOptions.MaxDegreeOfParallelism 设成 1 和 -1 的真实区别
设为 1 表示严格串行：同一时间最多一个消息在执行委托，后续消息排队等前一个完成；设为 -1 表示不限并发数 —— 但注意，这不等于“无限创建线程”，而是由 TaskScheduler 决定如何调度（默认走线程池，受启发式算法控制）。
- 误以为
-1就能“压满 CPU”，结果高吞吐下任务堆积、内存暴涨甚至OutOfMemoryException - I/O 密集型（如 HTTP 请求、文件读写）建议显式设为较小值（如
4–16），避免耗尽线程池 - CPU 密集型且无锁共享状态时，可设为
Environment.ProcessorCount，但需配合Task.Run显式移出同步上下文 - 永远不要在
TransformBlock委托里调用.Wait()或访问.Result，这是死锁高发区
多个 TransformBlock 串联后如何传播取消信号
关键不在块本身，而在初始化方式：LinkTo 不传递 CancellationToken，必须在每个块构造时显式传入 ExecutionDataflowBlockOptions 并设置 CancellationToken。上游块被取消，下游块不会自动感知 —— 它们各自独立响应自己的 token。
- 典型错误：只给第一个块传
cancellationToken，后面全用默认构造，导致取消后上游停了，下游还在空转或卡在未完成的异步操作上 - 正确写法：
new TransformBlock<string byte>(async url => ..., new ExecutionDataflowBlockOptions { CancellationToken = ct })</string> - 若某块内部有长时 I/O（如未超时的
HttpClient请求），还需在请求层单独加超时，不能只依赖 block 级 token
真正难的从来不是“怎么连起来”，而是每一段的 BoundedCapacity、MaxDegreeOfParallelism、是否启用 EnsureOrdered、以及下游消费速率跟不上时，上游是该阻塞、丢弃还是降级 —— 这些策略决定了整条流水线在压测下的稳定性，而不是开发时能不能跑通。
