std::lock_guard适用于进作用域加锁、出作用域释放的简单场景，仅支持自动raii加锁，不支持手动控制、转移或延迟加锁；std::unique_lock更灵活但开销大，适合需手动解锁、条件变量或所有权转移的复杂场景；std::scoped_lock是c++17起推荐的多互斥量安全加锁方案。
std::lock_guard 适合“进作用域就加锁、出作用域就释放”的简单场景
它只做一件事：构造时调用 lock()，析构时调用 unlock()，不支持手动控制、不能转移所有权、也不能延迟加锁。适合保护临界区短小、不需要中途解锁或重试的场合。
常见错误现象：std::lock_guard 被声明为函数参数（比如传值或 const 引用），导致锁在进入函数体前就释放了；或者试图对它调用 unlock() —— 它根本没这个成员函数。
- 用在局部变量声明里，比如
std::lock_guard<:mutex> lk(mtx);</:mutex> - 不要把它存成类成员（生命周期难控）
- 不支持
try_lock()或超时等待，遇到争抢只能阻塞 - 构造函数必须立即加锁，不接受
std::defer_lock等标记
std::unique_lock 支持延迟加锁、手动解锁、条件变量和所有权转移
它是可移动、可默认构造、可延迟初始化的锁包装器。真正需要灵活控制锁生命周期时才用它，比如配合 std::condition_variable::wait()，或者想先检查再决定是否加锁。
使用场景：等条件满足再加锁、临界区内要长时间等待（需先解锁避免阻塞别人）、多个互斥量需要按顺序加锁但又怕死锁（配合 std::scoped_lock 或 std::lock）。
立即学习“C++免费学习笔记（深入）”；
- 支持
std::defer_lock：声明时不加锁，后续调用lk.lock()或lk.try_lock() - 支持
lk.unlock()和lk.lock()多次切换，但注意别重复 lock 导致未定义行为 - 必须和
std::condition_variable::wait()配合使用，std::lock_guard不行 - 移动后原对象变为“未持有锁”状态，可安全销毁
别在不该移动的地方用 std::unique_lock
很多人以为“更高级 = 更好”，结果把 std::unique_lock 当成 std::lock_guard 的替代品无脑用，反而引入不必要的开销和风险。
性能影响：std::unique_lock 对象比 std::lock_guard 大（多一个指针或状态位），且构造/析构逻辑更重；兼容性上它要求互斥量支持 unlock() 和 try_lock()，而某些自定义锁可能只实现了基础接口。
- 如果只用到“自动 RAII 加锁”，选
std::lock_guard - 如果用了
std::move(lk)，确保接收方确实需要转移语义，不是误写 - 不要用
std::unique_lock去包装不支持try_lock()的锁类型，编译可能过，运行会崩 - 避免在循环内反复构造/析构
std::unique_lock，尤其带超时的try_lock_for()
std::scoped_lock 是 C++17 起更推荐的多锁方案
当你要同时锁多个互斥量（比如防止 AB-BA 死锁），别手写 std::unique_lock + std::lock() 组合，直接用 std::scoped_lock —— 它是 std::lock_guard 的多参数安全升级版。
容易踩的坑：有人仍用 std::unique_lock 分别构造再调 std::lock，既啰嗦又容易漏掉 std::adopt_lock 标记，导致二次加锁崩溃。
-
std::scoped_lock<:mutex std::mutex> lk(mtx1, mtx2);</:mutex>一行搞定，自动死锁避免 - 不支持延迟加锁，也不支持手动 unlock，语义比
std::unique_lock更严格、更轻量 - C++17 才有，老项目若不能升级，才退回到
std::unique_lock+std::lock手动组合
真正难的是判断“要不要提前解锁”——这往往暴露的是设计问题：临界区太长？数据结构没拆分？同步粒度太粗？锁本身只是工具，别让它掩盖架构里的紧耦合。
