std::lock_guard适用于作用域内自动加锁/解锁的简单同步场景，不支持延迟加锁、条件变量等待或手动控制；std::unique_lock则支持延迟加锁、条件变量配合、显式解锁重锁及移动语义，更灵活但开销略大。
std::lock_guard 适合什么场景
只在作用域内加锁、不需要手动控制解锁时机的简单同步。它构造时自动加锁，析构时自动释放，不能转移所有权，也不能延迟加锁。
- 适用于函数内局部保护临界区，比如
std::lock_guard<:mutex>包裹几行共享变量操作 - 不支持条件变量等待（因为无法临时释放锁）
- 构造函数必须立即尝试加锁；如果传入
std::defer_lock，编译直接报错 - 开销略小于
std::unique_lock，因无状态管理、无虚函数、无可移动性
std::unique_lock 支持哪些 std::lock_guard 做不到的事
它本质是可移动、可延迟、可手动控制生命周期的“增强版锁包装器”，核心价值不在“更安全”，而在“更灵活”。
- 支持延迟加锁：
std::unique_lock<:mutex> lk(mtx, std::defer_lock)，之后用lk.lock()或lk.try_lock() - 能配合
std::condition_variable::wait()使用——等待前自动释放锁，唤醒后自动重锁 - 可显式调用
lk.unlock()临时释放，再用lk.lock()拿回（需确保未被其他线程销毁） - 支持移动语义：可作为函数返回值或存入容器（
std::unique_lock是可移动不可复制的）
为什么不能用 std::lock_guard 等待条件变量
因为 std::condition_variable::wait() 要求锁类型满足 BasicLockable 且提供 unlock() 和 lock() 成员函数，而 std::lock_guard 只有隐式加锁和强制析构释放，没有公开的解锁接口。
- 写
cv.wait(lg, []{...})会编译失败，错误信息类似：no member named 'unlock' in 'std::lock_guard<:mutex>' -
std::unique_lock显式实现了这些接口，且保证了 wait 过程中锁的正确释放与重入 - 即使你手写循环 +
try_lock()模拟等待，也难保证原子性与唤醒丢失问题，不如直接用std::unique_lock+wait()
选型时容易忽略的性能与语义细节
两者都不是“越高级越好”。盲目用 std::unique_lock 可能引入不必要开销，而硬套 std::lock_guard 会卡死在条件同步上。
立即学习“C++免费学习笔记（深入）”；
-
std::unique_lock对象比std::lock_guard多一个布尔成员（记录是否已加锁），内存稍大，且构造/析构逻辑略复杂 - 若仅需 RAII 式临界区保护，用
std::lock_guard更清晰、更难误用（比如不会忘记 unlock） - 多个互斥量需同时加锁？优先用
std::scoped_lock（c++17），它比std::unique_lock+std::lock更简洁安全 - 跨作用域传递锁状态？确认接收方是否真的需要控制权——多数情况下，应重构为数据封装或消息传递，而非暴露锁对象
实际写并发代码时，锁对象的生命周期和作用域边界比函数名还重要；一个 std::unique_lock 被意外移动走，或者 std::lock_guard 被放在了错误的作用域层级，bug 往往在线程调度间隙才暴露。