ConcurrentBag 不是线程安全的通用 List 替代品，其 Add() 仅保证写入不崩溃而非全局即时可见，遍历时因依赖本地栈与全局池快照而漏数据；唯一可靠遍历方式是 while (bag.TryTake(out var item)) Process(item)。
ConcurrentBag
ConcurrentBag.Add() 线程安全，但遍历时为什么总漏数据？
因为 Add() 只保证“写入不崩溃”，不承诺“立刻全局可见”。它的内部是每个线程一个本地栈（thread-local stack），新元素先压入本线程栈；只有当该线程栈空了、或发生工作窃取（work-stealing）时，部分元素才会被迁移到全局池。遍历操作（如 foreach 或 ToArray()）只读取当前已合并的本地栈 + 全局池，其他线程尚未迁移的栈内容不会被包含。
- 高并发下
foreach (var x in bag)得到的是瞬时快照，可能漏掉刚Add()的项 -
bag.Count是近似值，返回 0 不代表真为空，可能还有待迁移的本地元素 -
TryPeek()同样受快照限制，不能用于判断“是否存在某类元素”
遍历 ConcurrentBag 的唯一可靠方式：用 TryTake 消费式取出
别试图“看一遍”，要“拿干净”。TryTake() 是唯一能跨线程合并状态、确保不漏元素的操作——它会主动从其他线程的本地栈中“偷”元素，直到所有可合并项都被取完。
- 正确写法：
while (bag.TryTake(out var item)) { Process(item); } - 错误写法：
while (bag.TryPeek(out var item)) { ... }—— 可能无限循环，也可能漏数据 - 如果必须转数组处理，
bag.ToArray()比foreach稍稳，但仍只是调用瞬间的快照，不包含“刚刚 Add 的那个”
什么时候该用 ConcurrentBag，什么时候不该用？
它不是为通用集合操作设计的，而是为两类明确场景优化：
- ✅ 适合：
Task.Run中线程自产自销（比如解析一批数据后把中间结果放回自己 bag）、多线程攒日志/事件，再由单个消费线程批量TryTake()清空 - ❌ 不适合：需要按插入顺序遍历、随机索引访问（
bag[0]不存在）、查某个值是否存在（bag.Contains(x)不支持）、做状态聚合或校验（要求“看到所有已添加项”） - ⚠️ 性能陷阱：线程数越多，内存占用越高——每个线程首次操作时分配独立本地栈（默认容量 32），线程退出后栈对象不会自动释放，长期运行服务中易成内存泄漏源
比 ConcurrentBag 更稳的选择：什么情况下该换？
一旦需求超出它的语义边界，硬扛只会让问题更隐蔽：
- 要 FIFO 顺序 + 强一致性 → 改用
ConcurrentQueue<t></t>，共享结构无 per-thread 开销 - 要随机访问或频繁
Contains查询 → 加锁保护普通List<t></t>，别用ConcurrentBag强撑 - 要做对象池 →
ConcurrentBag可用，但注意重置对象状态（如StringBuilder.Clear()），且优先考虑Microsoft.Extensions.ObjectPool.ObjectPool<t></t>
真正容易被忽略的是：ConcurrentBag 的“高性能”只在线程本地操作占比高时成立；一旦跨线程频繁互取，它就退化成普通并发集合水平——压测时若没控好线程数，很容易误判性能。
