mutex必须用RAII容器管理，禁用裸lock/unlock；需声明为全局、类成员或static局部变量，避免栈上临时对象；多锁须固定顺序或用std::lock；不可复制移动，生命周期须覆盖所有线程访问。
mutex 必须和 lock_guard 或 unique_lock 配合使用，不能手动调用 lock/unlock
直接调用 mutex::lock() 和 mutex::unlock() 极易出错：忘记 unlock、异常跳过 unlock、重复 unlock 都会导致死锁或未定义行为。C++ 标准库明确要求用 RAII 容器管理互斥量生命周期。
-
std::lock_guard<:mutex></:mutex>最常用：构造即加锁，析构自动解锁，不可移动、不可复制，适合简单临界区 -
std::unique_lock<:mutex></:mutex>更灵活：支持延迟加锁、条件变量配合、可移动，但开销略大 - 绝对不要裸用
mtx.lock()+mtx.unlock()—— 即使看起来“只有一行代码”也不安全
声明 mutex 时必须是全局、类成员或 static 局部变量，不能是栈上临时对象
把 std::mutex 声明在函数内部（比如放在 for 循环里）会导致每次调用都新建一个互斥量，线程根本没在争抢同一个锁，起不到同步作用。
- 正确做法：作为类的 private 成员变量（
mutable std::mutex mtx_;），或文件作用域 static 变量 - 错误写法：
void f() { std::mutex mtx; mtx.lock(); /* ... */ }—— 每次调用都是新锁 - 注意
mutable：若需在 const 成员函数中加锁（如缓存读取+更新），必须加此关键字
多个 mutex 加锁顺序不一致会引发死锁，必须固定顺序或用 std::lock
两个线程分别按不同顺序对 mtx_a 和 mtx_b 加锁，就可能互相等待——A 持有 a 等 b，B 持有 b 等 a。
- 推荐方案：所有代码统一按地址升序加锁，或约定逻辑顺序（如“先 account，再 log”）
- 更稳妥：用
std::lock(mtx_a, mtx_b)一次性锁住多个，再用std::lock_guard的带 defer 构造函数包装（std::defer_lock） - 避免嵌套锁：一个函数里不要在已持锁状态下调用可能再次加锁的其他函数
std::mutex 不可复制、不可移动，也不能跨线程传递所有权
试图把 std::mutex 放进 std::vector、传给 lambda 捕获、或作为函数返回值，编译直接报错：use of deleted function。
立即学习“C++免费学习笔记（深入）”；
- 正确做法：用指针或引用传递（如
void f(std::mutex& mtx)），或封装在类中通过 this 访问 - lambda 中捕获：只能用引用（
[&mtx]{ mtx.lock(); }），不能值捕获 - 想动态创建？用
std::unique_ptr<:mutex></:mutex>，但注意它只是管理内存，锁本身仍需按前述规则使用
实际中最容易被忽略的是：mutex 生命周期必须长于所有试图访问它的线程，且不能因对象析构而提前销毁。一旦锁对象被销毁，仍在运行的线程调用 lock() 就是未定义行为——不是报错，而是静默崩溃或数据错乱。
