concurrentbag.add() 线程安全但遍历时可能漏数据，因其采用线程本地栈+全局池设计，遍历仅反映调用瞬间可见状态；正确遍历应使用 trytake() 持续消费，而非 foreach 或 toarray()。
ConcurrentBag.Add() 看似安全，但遍历时可能漏数据
ConcurrentBag 是线程安全的添加/取出容器，但它的设计目标不是“强一致性遍历”——foreach 或 ToArray() 得到的快照，不保证包含所有已 Add() 的元素，尤其在高并发写入时。这是因为它的内部实现用的是每个线程私有的本地栈（thread-local stack），新元素先压入本地栈；只有当本地栈空了、或发生线程迁移时，才把部分元素“偷”到全局池。遍历时只读取当前可见的本地栈 + 全局池，而其他线程的本地栈可能还没被合并。
- 适用场景：大量线程频繁
Add()，后续统一消费（比如日志缓冲、事件暂存），不依赖“实时全量可见” - 不适用场景：需要严格按插入顺序遍历、或要求遍历时看到“所有已添加项”的逻辑（如状态聚合、校验）
- 避免用
Count判断是否为空——它只是近似值，可能返回 0 即使还有待合并的本地元素
遍历 ConcurrentBag 的正确姿势：别直接 foreach
直接 foreach (var item in bag) 会触发内部快照逻辑，结果不可靠。真正安全的遍历方式是“消费式取出”，即用 TryTake() 持续取直到失败，这能确保拿到所有已归并的元素（包括从其他线程本地栈迁移来的）。
- 如果必须转成数组再处理：用
bag.ToArray()比foreach稍稳，但它仍不保证包含“刚刚 Add 的那个”，仅反映调用瞬间的合并状态 - 若需强一致性，改用
ConcurrentQueue<t></t>（FIFO 保证）或加锁保护普通List<t></t>，别硬扛 ConcurrentBag 的语义边界 -
TryPeek()只看不取，同样受快照限制，不能用于判断“是否存在某类元素”
ConcurrentBag 的性能陷阱：Add() 快，但内存占用随线程数线性涨
每个线程第一次操作 ConcurrentBag 时，都会分配一个独立的本地栈（默认初始容量 32）。线程越多，未释放的本地栈越多；即使线程退出，这些栈对象也不会自动回收，除非 ConcurrentBag 被 GC —— 它不实现 IDisposable，也没有清理 API。
- 长期运行的服务中，若频繁创建短期线程（如 Task.Run 不复用线程池），
ConcurrentBag实例容易成为内存泄漏源 - 对比
ConcurrentQueue<t></t>：后者共享单一结构，无 per-thread 开销，适合线程数不确定的场景 - 测试时注意：用
ThreadPool.SetMinThreads()控制线程数，避免压力测试误判为“性能好”
ConcurrentBag 和 lock(List) 怎么选
不是“线程安全就一定比加锁好”。ConcurrentBag 的优势只在“极高频、无序、只进不出”的写入场景；一旦涉及查找、删除、顺序保证或低频写入，lock 包裹的 List<t></t> 往往更简单、更省内存、更容易调试。
- 写入频率低（Contains() /
Remove()/ 索引访问 → 直接lock+List<t></t> - 纯生产者场景（如 Web API 接收请求后塞进 Bag，后台定时批量处理）→
ConcurrentBag合理 - 多个线程既写又读，且读操作要反映最新写入 → 改用
ConcurrentDictionary<tkey tvalue></tkey>或信号量协调
Add() 和 TryTake() 这对操作，其余行为都属于实现细节。用错地方时，问题往往延迟暴露——数据偶尔丢失、内存缓慢上涨、压测时吞吐骤降。盯住你的实际读写模式，而不是名字里的 “Concurrent”。
