应先确认丢包环节再决定是否用 std::atomic：日志显示 push 成功但 pop 未读到，才可能是竞态；若 push 未执行或 pop 空队列未判空，则属逻辑错误。
用 std::atomic 替代裸变量前先确认是否真在共享写
丢包常被误判为“线程竞争”，实际可能是逻辑错误：比如多个线程往同一个 std::queue push，但只有单个线程 pop，而 pop 侧没处理空队列就直接取 front —— 这不是竞态，是逻辑缺陷。先加日志确认丢包发生在哪一环：push 成功但 pop 永远没读到？还是 push 根本没执行？用 std::cout （注意加 <code>std::flush 或换行）快速验证，比一上来上锁更高效。
加锁范围必须覆盖完整临界区，尤其注意异常路径
常见坑是只锁了 push，但没锁 size() 或 empty() 判断——这两个函数本身不修改状态，但和后续的 front()/pop() 构成原子操作需求。例如：
std::lock_guard<std::mutex> lk(mtx);
if (!q.empty()) { // ✅ 这里锁住了
auto x = q.front(); // ❌ 但 front() 返回引用，q 可能被其他线程 pop 掉
q.pop(); // ❌ 若 pop 前发生调度，x 已失效
}
正确做法是把 front 和 pop 放在同一锁内，或改用线程安全的封装（如 concurrent_queue）。另外，如果 push 中抛异常，锁会自动释放，但若你手动用了 mtx.lock() 没配 try/catch，就会死锁。
用 std::shared_mutex 优化读多写少场景时别误用 shared_lock
当多个消费者线程频繁检查队列是否为空、但只有少数生产者写入时，std::shared_mutex 能提升吞吐。但注意：std::shared_lock 只防写，不防其他读线程的并发访问；它不能替代互斥量来保护数据一致性。比如：
立即学习“C++免费学习笔记（深入）”；
std::shared_lock<std::shared_mutex> slk(rw_mtx); // 允许多个读
if (q.size() > 0) {
auto x = q.front(); // ❌ 仍可能被写线程中途清空
q.pop(); // ❌ 这里需要独占锁
}
真正安全的做法是：读判断用共享锁，实际取/删操作必须升级为独占锁（std::unique_lock），或者干脆避免分离判断与操作——直接尝试 try_pop 类接口。
用 ThreadSanitizer 快速暴露未定义行为
Clang/GCC 编译时加 -fsanitize=thread，运行时会报告所有数据竞争点，包括那些看似“不会出事”的读写混合（比如一个线程写 int flag，另一个线程读它来决定是否退出循环）。它不依赖日志，直接定位到代码行。但要注意：TSan 会显著拖慢速度、增大内存占用，且不支持某些系统调用（如 fork）；调试时关掉优化（-O0），否则可能漏报。
真正难的是那些“偶发丢包”：比如两个线程交替 push 同一 packet 结构体，但结构体里有指针成员指向栈内存——这时不是竞争，是悬垂指针。这种问题 TSan 不报，得靠 AddressSanitizer 配合检查。
