blockingcollection 在需“生产者通知消费者结束”或“容量限制触发背压”时不可替代：支持 completeadding() 使消费者自然退出，内置 boundedcapacity 实现阻塞式限流；concurrentqueue 无此能力，需手动轮询且无容量控制。
BlockingCollection 什么时候必须用，而不是 ConcurrentQueue
当你需要「生产者通知消费者已结束」或「队列容量上限触发背压」时，BlockingCollection<t></t> 不可替代。比如后台任务批量拉取日志后标记“不再有新数据”，消费者靠 CompleteAdding() 自然退出循环；又比如内存敏感场景下限制最多缓存 1000 条待处理消息，超限时生产者自动阻塞，而不是丢弃或抛异常。ConcurrentQueue<t></t> 虽快且无锁，但没 CompleteAdding()、不支持容量限制、空队列时 TryDequeue() 立即返回 false —— 你得自己写 while + Thread.Sleep() 或 ManualResetEvent，容易误判或浪费 CPU。
构造时传入容量参数的陷阱
BlockingCollection<t></t> 的有界行为完全依赖构造时传入的 boundedCapacity 参数，但这个值只约束内部封装的集合（默认是 ConcurrentQueue<t></t>），不控制外部并发调用节奏。常见错误是以为设了 100 就绝对安全，结果仍 OOM：
- 多个线程同时调用
Add()，在判断容量前可能已有数个线程通过检查，导致瞬时超限 -
boundedCapacity不影响Take()行为，只管“加”；但若消费者太慢，内存压力仍在累积 - 如果用自定义
IProducerConsumerCollection<t></t>（如优先队列），容量语义由其实现决定，未必是元素个数
真正稳住内存的方法是：容量设保守值（如预估峰值的 70%）+ 生产者侧加超时重试逻辑（用 Add(item, timeoutMs)）+ 监控 Count 属性趋势。
Take() 和 TryTake() 的阻塞逻辑差异
Take() 在队列为空且未调用 CompleteAdding() 时永久阻塞，线程挂起不消耗 CPU；一旦 CompleteAdding() 被调用，再 Take() 就抛 InvalidOperationException。而 TryTake(out T item, int millisecondsTimeout) 是可控的：超时返回 false，不抛异常，适合做带心跳的消费者。
- 用
Take()时必须确保有线程调用CompleteAdding()，否则消费者永远卡住 -
TryTake()的 timeout 设 0 表示非阻塞轮询；设 -1 等价于Take()；设正数才真正有用 - 二者都支持
CancellationToken重载，但TryTake()的 token 触发时返回 false，Take()则抛OperationCanceledException
Dispose() 必须显式调用，且不能只靠 using
BlockingCollection<t></t> 内部持有信号量等同步原语，Dispose() 会释放这些资源。如果只用 using 块但块内发生未捕获异常，Dispose() 可能不执行 —— 导致后续程序中出现奇怪的线程挂起或内存泄漏。更隐蔽的问题是：它包装的底层集合（如 ConcurrentQueue<t></t>）本身不需要 Dispose()，所以很多人误以为整个对象也无需释放。
- 始终在
try/finally中手动调用Dispose()，尤其在线程长期运行的后台服务里 - 不要把
BlockingCollection<t></t>存在静态字段中，除非你明确管理其生命周期 - 如果用了
GetConsumingEnumerable()，枚举器本身不拥有集合，必须单独处置集合实例
最易被忽略的是跨线程共享同一个 BlockingCollection<t></t> 实例时，Dispose 时机难协调 —— 建议用 CancellationTokenSource 控制整体生命周期，Dispose 前先调用 CompleteAdding()，再等待所有消费者线程自然退出。
