ConcurrentBag适用于同一线程自产自销或多线程攒数据、单线程批量清空场景；不适用于需顺序访问、随机索引或Contains查询的场合。
ConcurrentBag 什么时候该用，什么时候不该用
它不是万能的线程安全 List 替代品。如果你需要按插入顺序消费、要随机访问、要查某个特定值是否存在，ConcurrentBag 就不合适——它不支持索引、没有 Contains、遍历时顺序不可靠。真正适合它的场景就两类：同一线程自产自销（比如线程池里处理一批任务后把中间结果放回自己 bag），或多线程快速攒数据、单线程批量清空（如日志缓冲区）。用错场景，性能反而不如加锁的 List<t></t>。
Add 和 TryTake 是核心，但 TryPeek 很容易被误用
TryPeek 看似方便，但它只保证“当前能看到一个元素”，不保证这个元素没被别的线程同时 TryTake 走。在高并发下，TryPeek 返回 true 后立刻调 TryTake，仍可能失败——这不是 bug，是设计使然。实际编码中，应优先用 TryTake 循环取，而不是“先看再拿”：
while (bag.TryTake(out var item))
{
Process(item);
}
而不是：
while (bag.TryPeek(out var item)) // ❌ 可能无限循环或漏数据
{
if (bag.TryTake(out _)) { ... }
}
遍历 ConcurrentBag 是个隐藏陷阱
foreach 遍历 ConcurrentBag 会触发一次全量快照（内部合并所有线程本地袋），时间复杂度 O(n)，且期间新增的元素不一定被包含。更关键的是：遍历时无法保证线程安全地增删——虽然不会崩溃，但可能漏掉刚被其他线程添加的项，或重复看到已被取走的项。所以除非是低频、只读、可容忍不一致的监控场景，否则别在生产逻辑里 foreach 它。真要“扫一遍”，建议先 ToArray() 再处理，明确知道这是个瞬时快照。
对象池是它最自然的用武之地
创建开销大的对象（比如 StringBuilder、自定义解析器实例），用 ConcurrentBag 做池子非常顺手：线程用完直接 Add 回去，下次 TryTake 拿，90% 情况下都是无锁操作。注意两点：
• 不要往 bag 里塞 null 或已释放对象；
• 如果对象有状态，务必在 TryTake 后重置（如 Clear()），否则下次拿到的是脏数据；
• .NET 已提供 Microsoft.Extensions.ObjectPool.ObjectPool<t></t>，简单场景直接用它更稳妥，ConcurrentBag 更适合作为底层存储自建轻量池。
它真正的优势不在“线程安全”这个标签，而在于“让每个线程尽量不碰别人的东西”。一旦跨线程频繁互取，性能就会滑向普通并发集合的水平——这点在压测时很容易被忽略。
