std::unique_lock支持手动unlock、延迟构造、try-lock、move语义及配合condition_variable；std::lock_guard仅RAII自动加锁/解锁，不可干预、不可移动、无状态、更轻量。
std::unique_lock 支持手动 unlock()，lock_guard 完全不支持
这是最直接的差异：std::unique_lock 是可移动、可延迟、可手动控制的锁包装器；而 std::lock_guard 一旦构造就立即加锁，析构时自动释放，中间**无法干预**。如果你需要在临界区中途释放锁（比如等待条件变量、避免锁粒度太粗），只能用 std::unique_lock。
常见错误现象：std::lock_guard 对象在作用域内“想提前放锁”却找不到 unlock() 方法，编译报错：error: 'class std::lock_guard<:mutex>' has no member named 'unlock'。
- 适用场景：调用
std::condition_variable::wait()必须传入std::unique_lock，因为 wait 内部会先 unlock，唤醒后再重新 lock - 手动解锁示例：
std::mutex mtx; std::unique_lock
std::unique_lock 支持延迟构造和 defer_lock 参数
std::lock_guard 构造即加锁，没有选择；std::unique_lock 可以用 std::defer_lock 标签初始化，不立刻持有锁——这让你能把加锁时机和锁对象生命周期解耦。
使用场景：实现 try-lock、多锁按序获取、或根据运行时条件决定是否加锁。
立即学习“C++免费学习笔记（深入）”；
-
std::unique_lock<:mutex> lk(mtx, std::defer_lock);→ 构造时不加锁 -
if (lk.try_lock()) { /* 成功进入临界区 */ }→ 非阻塞尝试 -
std::unique_lock<:mutex> lk1(mtx1, std::defer_lock), lk2(mtx2, std::defer_lock); std::lock(lk1, lk2);→ 避免死锁的批量加锁
性能与内存开销：unique_lock 更重，但代价通常可接受
std::lock_guard 是零开销抽象：它只是个 RAII 封装，不带状态，sizeof 通常等于一个指针（甚至更小）；std::unique_lock 内部需记录是否已加锁、是否拥有锁等状态，有轻微内存和指令开销。
不过，在绝大多数真实场景中，这点开销远小于锁本身的系统调用或缓存争用成本。别为了省几个字节放弃灵活性——除非你在超低延迟、高频短临界区的嵌入式实时系统里手写锁逻辑。
- 典型 sizeof 差异（x64）：
sizeof(std::lock_guard<:mutex>)≈ 1，sizeof(std::unique_lock<:mutex>)≈ 16 - 不要用
std::unique_lock替代std::lock_guard仅仅为了“统一风格”——没 unlock / defer / transfer 需求时，std::lock_guard更清晰、更轻量、意图更明确
unique_lock 支持 move 语义，lock_guard 不可拷贝也不可移动
std::unique_lock 可以 move（比如返回局部锁、传入 lambda 捕获），std::lock_guard 连 move 都被禁用（删除了移动构造函数）。这不是“强弱”问题，而是设计定位不同：前者是锁的“句柄”，后者是“作用域绑定锁”。
容易踩的坑：试图把 std::lock_guard 存进容器、作为函数返回值、或用在需要转移所有权的地方，编译直接失败。
- 合法示例：
std::unique_lock
- 非法示例：
std::lock_guard<:mutex> lg(m); auto x = std::move(lg);→ 编译错误
真正关键的不是“哪个更强”，而是“你是否需要 unlock、defer、try、move 或配合 condition_variable”。不需要时，std::lock_guard 更安全、更轻、意图更干净；一旦涉及任何动态锁控制，std::unique_lock 就不是可选项，而是唯一解。
