BlockingCollection 的阻塞由 Take() 和 GetConsumingEnumerable() 主动触发，非自动；Take() 在空且未完成时挂起线程，CompleteAdding() 后空集合调用 Take() 抛 InvalidOperationException；GetConsumingEnumerable() 是 Take() 的懒迭代封装，不启新线程，多消费者需各自获取枚举器并依赖 CompleteAdding() 协作终止。
BlockingCollectionTake() 和 GetConsumingEnumerable() 主动触发阻塞——不调用它们，线程根本不会停。
为什么 Take() 会卡住？
这是最常被误解的一点：阻塞不是自动发生的，而是 Take() 在集合为空且未标记完成时主动挂起当前线程。
- 如果集合为空，
Take()会一直等待，直到有新元素入队或调用CompleteAdding() - 若已调用
CompleteAdding()且集合为空，Take()立即抛出InvalidOperationException：“无法从已完成添加的BlockingCollection中取元素” - 注意：
Take()是单次操作；想持续消费，得写循环，不能只调一次就指望它“自动拉取”
GetConsumingEnumerable() 的真实行为
它返回一个“懒迭代器”，每次 foreach 取值时才调用 Take() —— 所以它只是语法糖，底层仍是阻塞式 Take()。
- 一旦
CompleteAdding()被调用，枚举会在遍历完剩余元素后自然退出，不会抛异常 - 但如果你在枚举中途调用
CompleteAdding()，当前正在阻塞的那一次Take()仍会立即返回（或抛异常？不，它会返回剩余项，直到空）——准确说：它只影响后续阻塞，不影响已进入的等待 - 别把它当成“后台消费者”：它不启新线程，
foreach仍在当前线程同步执行
多消费者场景下容易漏掉的要点
多个线程同时调用 Take() 或遍历 GetConsumingEnumerable() 是安全的，但需注意协作终止逻辑。
- 必须由生产者（或协调方）调用
CompleteAdding()，否则所有消费者线程将永远阻塞在Take() - 没有内置“全部消费完毕”的通知机制：你无法知道“最后一个元素已被取走”，只能靠
CompleteAdding()+ 消费者自行判断是否该退出 - 若使用
GetConsumingEnumerable()，多个消费者不能共享同一个枚举器实例（会报InvalidOperationException：“枚举器已被使用”）；每个线程应各自调用该方法获取独立枚举器
真正难处理的不是阻塞本身，而是“什么时候该停止等待”——CompleteAdding() 的调用时机、跨线程可见性、以及消费者如何感知“终结信号”，这些才是实际项目里最容易出错的地方。
