std::lock_guard适用于简单场景，构造时加锁、析构时解锁，不可手动控制；std::unique_lock支持延迟加锁、手动解锁、条件变量配合及所有权转移，更灵活但有轻微开销。
在C++多线程编程中，std::lock_guard 和 std::unique_lock 都是用来管理互斥量（mutex）的RAII类，确保在作用域结束时自动释放锁。虽然它们目标一致，但在灵活性和使用场景上有明显区别。
1. 基本特性对比
std::lock_guard 是最简单的锁管理工具，构造时加锁，析构时解锁，不支持手动控制加锁或解锁过程。它轻量、高效，适用于锁生命周期与作用域完全一致的场景。
std::unique_lock 更加灵活，同样遵循RAII原则，但它允许延迟加锁、尝试加锁、手动解锁，甚至可以将锁转移给其他 unique_lock 对象（支持移动语义）。这使得它适合更复杂的同步逻辑。
2. 加锁时机与控制能力
std::lock_guard 在构造函数中立即锁定互斥量，无法选择延迟加锁：
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx;
void func() {
std::lock_guard<std::mutex> lock(mtx); // 立即加锁
// 临界区操作
} // 自动解锁
std::unique_lock 提供多种构造方式，包括不加锁创建：
std::mutex mtx;
void func() {
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);
// 此时不加锁
// ... 其他操作
lock.lock(); // 手动加锁
// 临界区
lock.unlock(); // 可提前解锁
// 其他非临界操作
} // 析构时若仍持有锁会自动释放
3. 支持条件变量与所有权转移
std::unique_lock 能与 std::condition_variable 配合使用，这是 lock_guard 不支持的关键功能：
std::mutex mtx;
std::condition_variable cv;
bool ready = false;
// 等待线程
void wait_task() {
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, []{ return ready; });
// 继续执行
}
这里 condition_variable::wait() 需要传入一个 unique_lock，因为它需要临时释放锁并等待唤醒后再重新获取。
此外，unique_lock 支持移动语义，可将锁的所有权从一个对象转移到另一个：
std::unique_lock<std::mutex> get_lock() {
std::unique_lock<std::mutex> lock(mtx);
return lock; // 移动返回
}
4. 性能与适用场景
由于 std::lock_guard 功能简单，没有额外状态管理开销，性能略优于 unique_lock，是局部作用域内简单加锁的首选。
std::unique_lock 因为内部维护了是否已加锁等状态信息，有轻微运行时开销，但换来更大的控制自由度，适合以下情况：
- 需要延迟加锁或多次加/解锁
- 配合条件变量使用
- 需将锁作为返回值或参数传递
- 实现细粒度的资源控制逻辑
基本上就这些。选择哪个取决于具体需求：追求简洁高效用 lock_guard；需要灵活性则选 unique_lock。
