std::mutex必须配合RAII机制使用，裸调用lock()/unlock()易因异常、提前return或分支遗漏导致死锁；应优先用std::lock_guard自动管理锁，避免重复lock引发未定义行为，且须确保所有数据访问路径均受保护。

std::mutex 必须和 std::lock_guard 配合使用，裸调用 lock()/unlock() 极易出错

直接调用 mutex.lock() 和 mutex.unlock() 是高危操作：异常、提前 return、逻辑分支遗漏都会导致 unlock 没被执行，造成死锁或资源永久占用。正确做法是依赖 RAII——用 std::lock_guard 在作用域开始自动加锁，离开作用域时自动解锁。

常见错误场景包括：

• 函数中有多处 return，只在末尾 unlock
• try-catch 中 catch 了异常但没 unlock
• 循环内加锁后 break 跳出，忘记 unlock

std::mutex mtx;
int shared_value = 0;

void safe_increment() {
    std::lock_guard lock(mtx); // 自动构造即加锁
    ++shared_value;                         // 临界区
} // 自动析构即解锁 —— 即使此处抛异常也安全

不要对同一个 mutex 多次 lock，否则会死锁（尤其是递归场景）

std::mutex 不支持递归加锁。如果同一线程重复调用 lock()，行为是未定义的（多数实现直接阻塞自身，形成死锁）。即使你“确定”不会递归调用，编译器优化或间接调用链也可能打破这个假设。

替代方案：

立即学习“C++免费学习笔记（深入）”；

• 重构代码，避免临界区嵌套
• 必要时改用 std::recursive_mutex（但应视为设计警告信号）
• 用 std::unique_lock + try_lock() 显式控制，避免盲等

注意：std::recursive_mutex 有额外开销，且掩盖了本该被发现的同步设计缺陷。

保护的是数据访问路径，不是变量本身；漏掉任何一处读/写就等于没保护

一个 std::mutex 只对显式用它保护的代码段起作用。如果某处修改 shared_value 没加锁，哪怕其他 99 处都加了，数据竞争依然存在。尤其容易忽略：

• 调试打印（std::cout ）
• 结构体/类的成员函数中隐式访问共享字段
• lambda 捕获后在新线程中直接读写
• std::vector::push_back() 等可能触发重分配并复制元素的容器操作

建议把共享数据封装成类，将 mutex 作为私有成员，所有访问通过加锁的公有方法进行：

class Counter {
    mutable std::mutex mtx; // mutable 允许 const 成员函数中加锁
    int value = 0;
public:
    void increment() { std::lock_guard l(mtx); ++value; }
    int get() const { std::lock_guard l(mtx); return value; }
};

std::mutex 不能拷贝，只能移动；跨线程传递必须用指针或引用

std::mutex 的拷贝构造函数和赋值运算符都被删除了。试图 std::thread t(func, mtx) 会编译失败——因为 std::thread 默认按值传递参数，触发拷贝。

正确方式只有两种：

• 用 std::ref(mtx) 传引用：std::thread t(func, std::ref(mtx))
• 传指针：std::thread t(func, &mtx)，并在函数内用 *mtx_ptr 访问

切记：传值 = 编译错误；传 std::move(mtx) = 移动后原 mutex 失效，后续使用崩溃。