std::mutex必须配合RAII类（如std::lock_guard或std::unique_lock）使用，裸调lock()/unlock()易因异常、提前return等导致死锁；多锁需统一顺序或用std::scoped_lock避免AB-BA死锁；mutex不可复制移动，应为private成员并禁用拷贝；递归需求才用std::recursive_mutex；关键在合理界定共享数据与临界区粒度。
std::mutex 必须配合 std::lock_guard 或 std::unique_lock 使用
直接调用 mutex.lock() 和 mutex.unlock() 极易出错——忘记 unlock、提前 return、抛异常都会导致死锁。C++ 标准库不推荐裸调用，而是靠 RAII 自动管理生命周期。
实操建议：
std::lock_guard最常用：构造即加锁，析构即解锁，不能转移，轻量且安全std::unique_lock用于需要延迟加锁、手动解锁、或配合条件变量的场景- 永远不要在同一个线程里对已持有的
std::mutex再次调用lock()—— 这是未定义行为，多数实现会死锁
多个 mutex 加锁顺序不一致会引发死锁
两个线程分别按不同顺序获取 mtx_a 和 mtx_b，比如线程1先锁 a 再锁 b，线程2先锁 b 再锁 a，就可能互相等待对方释放——典型 AB-BA 死锁。
实操建议：
- 所有代码路径中，对一组 mutex 的加锁顺序必须严格一致（例如始终按地址大小排序）
- 用
std::scoped_lock（C++17 起）一次性加多个锁，它内部自动按地址排序并避免死锁：std::scoped_lock lock(mtx_a, mtx_b); - 旧标准可用
std::lock(mtx_a, mtx_b)+std::lock_guard的组合，但更啰嗦
std::mutex 不可复制、不可移动，别传值或存 vector
常见错误：把 std::mutex 成员变量设为 public，然后意外被拷贝；或试图 std::vector —— 编译直接失败，因为 std::mutex 删除了拷贝和移动构造函数。
实操建议：
- mutex 应作为类的 private 成员，且类本身也应禁用拷贝（显式删除
MyClass(const MyClass&) = delete;） - 需要 N 个互斥资源？用
std::vector或静态数组，而不是直接存对象 - 跨线程共享 mutex？不行——mutex 只能在线程内持有，且不能跨线程传递所有权；它只是同步原语，不是数据载体
递归锁不是默认选项，std::recursive_mutex 要主动选
有些场景确实需要同一线程多次进入临界区（比如递归函数调用），但 std::mutex 不支持。有人误以为“加锁两次就自动递归”，结果程序卡死。
实操建议：
- 明确需要递归语义时，才用
std::recursive_mutex，并配std::lock_guard或std::unique_lock - 注意性能开销：递归锁内部要维护计数器和持有线程 ID，比普通
std::mutex重 - 绝大多数业务逻辑不需要递归锁——重新设计函数边界、提取临界区外的公共逻辑，通常比用递归锁更清晰、更安全
真正难的不是写对 lock/unlock，而是判断哪段数据算“共享”、哪个粒度该加锁、以及锁住之后是否还调用了可能阻塞或抛异常的第三方代码——这些地方一漏，std::mutex 就成了幻觉。
