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<std::mutex> 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<std::mutex> l(mtx); ++value; }
int get() const { std::lock_guard<std::mutex> 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 失效，后续使用崩溃。
lock_guard 的写法。 
