std::lock_guard适用于进作用域加锁、出作用域解锁的简单场景，仅支持自动加锁/解锁，不支持手动控制；std::unique_lock则支持延迟加锁、手动unlock、条件变量协作及移动语义，适用于复杂同步需求。
std::lock_guard 适合「进作用域就加锁、出作用域就解锁」的简单场景
它只做一件事：构造时调用 mutex.lock()，析构时调用 mutex.unlock()，不支持手动解锁、延迟加锁或转移所有权。如果你的临界区逻辑是连续的、无分支跳转、也不需要中途释放锁（比如为了调用可能阻塞的函数），std::lock_guard 是最轻量且最不容易出错的选择。
常见错误现象：有人试图对 std::lock_guard 调用 unlock() 或 release() —— 这些成员函数根本不存在，编译直接报错：error: 'class std::lock_guard<:mutex>' has no member named 'unlock'</:mutex>。
实操建议：
- 优先用于函数内短小、确定性的临界区，例如保护一个
std::vector的push_back()操作 - 配合
std::scoped_lock（C++17）一起用，能安全地同时锁定多个互斥量，避免死锁 - 不要把它声明为类成员变量——它的生命周期必须严格绑定到某一段代码块，否则会导致锁持有时间远超预期
std::unique_lock 支持延迟加锁、手动解锁和条件变量协作
它比 std::lock_guard 多一层抽象：内部持有对互斥量的可选引用，并记录当前是否已上锁。这意味着你可以控制加锁时机（比如先构造再调用 lock()）、主动 unlock()、甚至把锁“移动”给另一个 std::unique_lock 实例（但原实例变为空状态）。
立即学习“C++免费学习笔记（深入）”；
使用场景集中在两类：一是需要在加锁前做判断或准备（如检查某个条件是否满足再决定是否进入临界区）；二是必须与 std::condition_variable 配合——因为 wait() 要求传入一个可手动解锁的锁对象，std::lock_guard 不满足这个接口契约。
实操建议：
- 和
std::condition_variable::wait()一起使用时，必须用std::unique_lock - 若需在临界区内调用可能长时间阻塞的函数（如 I/O 或网络请求），应先
unlock()再调用，避免锁粒度过大 - 注意默认构造的
std::unique_lock是“未关联任何互斥量”的空状态，此时调用lock()会崩溃；必须先通过赋值或构造函数绑定有效互斥量
性能差异几乎可以忽略，但语义误用会导致严重 bug
两者底层都只是管理一个互斥量指针和一个布尔标记（是否已加锁），没有动态内存分配。构造/析构开销差异在纳秒级，完全不该成为选型依据。真正影响系统行为的是语义误用。
容易踩的坑：
- 把
std::unique_lock当成更“高级”的std::lock_guard来滥用：比如全程不用unlock()、也不配合条件变量，却多写了一行模板参数，徒增可读性负担 - 在 lambda 或异步回调中捕获了持有锁的
std::unique_lock，结果锁的生命周期被延长到回调执行时——而此时原始作用域早已退出，导致悬空或重复解锁 - 误以为
std::unique_lock的移动语义能“传递锁的所有权”——实际上它只是转移管理权，底层互斥量仍是共享的；两个std::unique_lock同时指向同一std::mutex并尝试加锁，依然会阻塞或抛异常（取决于互斥量类型）
一个典型对比示例：生产者-消费者中的锁使用
下面这段代码展示了两种锁在实际协作逻辑中的不可替代性：
std::queue<int> buffer;
std::mutex mtx;
std::condition_variable cv;
// 生产者：用 unique_lock + wait_for 避免忙等
void producer() {
std::unique_lock<std::mutex> lk(mtx);
while (buffer.size() >= MAX_SIZE) {
if (cv.wait_for(lk, 100ms) == std::cv_status::timeout) {
return; // 超时退出
}
}
buffer.push(42);
lk.unlock(); // 主动释放，避免阻塞消费者
cv.notify_one();
}
// 消费者：同样需要 unique_lock 才能 wait
void consumer() {
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, []{ return !buffer.empty(); });
int val = buffer.front();
buffer.pop();
// 自动析构时 unlock
}
这里如果把 std::unique_lock 换成 std::lock_guard，第一行 cv.wait(lk, ...) 就无法编译——因为 wait 要求锁对象提供 unlock() 和 lock() 成员函数。
真正该纠结的不是“哪个好”，而是“我此刻要解决什么同步问题”。锁不是越灵活越好，而是刚好够用、不易误用的那个才最好。
