直接用 std::mutex::lock()/unlock() 极易出错：异常导致漏解锁、多 return 路径遗漏 unlock、重复 lock/unlock 引发未定义行为；应优先使用 std::lock_guard 实现 raii 自动管理，仅在需手动控制时选用 std::unique_lock。
直接用 std::mutex::lock() 和 std::mutex::unlock() 是可行的，但极容易出错——比如异常跳过 unlock()、提前 return 忘了解锁、或者重复解锁。实际项目里几乎没人这么干。
手动 lock/unlock 的坑在哪
看似最直白的方式，反而最容易引入死锁或资源泄漏：
-
lock()后如果临界区抛异常，unlock()就永远不会执行 - 多个 return 路径时，容易漏掉某一处的
unlock() - 同一个线程对同一
std::mutex重复调用lock()会直接导致未定义行为（不是阻塞，是崩溃或静默失败） -
unlock()被调用两次，行为未定义——多数实现会 abort 或 segfault
std::lock_guard 是默认选择
它用 RAII 确保加锁和解锁严格配对，无论函数怎么退出（return、throw、goto），析构都会发生：
示例：std::mutex mtx;void safe_update() { std::lock_guard<:mutex> lock(mtx); // 构造即 lock</:mutex> shared_data++; // 函数结束时 lock 析构，自动 unlock}
注意：std::lock_guard 不支持移动、不支持延迟加锁、不能手动 unlock() —— 这恰恰是它的设计目标：简单、确定、零风险。
std::unique_lock 适合需要灵活控制的场景
当你必须提前释放锁、尝试加锁、或把锁传给其他函数时，才用它：
-
std::unique_lock<:mutex> lock(mtx, std::defer_lock);</:mutex>—— 声明但不立即加锁 -
lock.lock();/lock.unlock();—— 手动控制生命周期 -
if (lock.try_lock()) { ... }—— 非阻塞尝试获取 -
std::move(lock)可转移锁所有权（比如传入std::condition_variable::wait()）
代价是对象更大、构造/析构稍慢，且仍需你保证逻辑正确——它不防止你犯错，只是给了你更多操作权。
别用 std::mutex 直接递归加锁
同一个线程对普通 std::mutex 多次调用 lock() 是未定义行为。如果代码路径天然存在嵌套（比如回调、递归函数、事件循环中重入），必须换用 std::recursive_mutex，并确保 lock()/unlock() 次数严格匹配——std::lock_guard 和 std::unique_lock 对它同样适用，但底层语义不同。
真正容易被忽略的是：递归锁性能略差、调试器可能无法准确报告持有者，而且它掩盖了本可通过重构消除的重入问题。除非真有不可规避的嵌套调用，否则优先考虑拆分临界区或改用消息队列。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
