最典型锁类型错配是写操作误用std::shared_mutex::lock_shared()，导致多写线程并发修改共享变量；正确写法必须用lock()或lock_upgrade()。
用 std::mutex 保护读多写少的场景，性能会明显拖垮；用 std::shared_mutex 却在写操作里只加 lock_shared()，数据就直接乱了——这不是死锁，也不是崩溃，而是逻辑错：结果不可重现、偶尔出错、调试器抓不到现场。
std::shared_mutex 写操作误用 lock_shared()
这是最典型的“锁类型错配”：写线程调用了 lock_shared()，以为能进临界区，实际只获得读权限。多个写线程同时进入，++counter 这种非原子操作立刻产生竞态。
- 现象：程序不卡死，但共享变量值随机偏小，日志打印顺序错乱，且每次运行结果不同
- 正确写法必须是
lock()（或lock_upgrade()+unlock_upgrade_and_lock()） -
lock_shared()和lock()不可混用在同一把std::shared_mutex上做写保护——前者不排斥其他lock_shared()，但会阻塞lock()；后者才真正互斥所有访问
std::recursive_mutex 被当普通 mutex 用
递归锁允许同一线程重复加锁，本意是解决函数重入问题。但如果误以为它比 std::mutex “更安全”，在跨线程场景下随意替换，反而掩盖了真正的设计缺陷。
- 现象：单线程测试全过，多线程一跑就数据错，但无 crash、无死锁提示
- 根本问题：递归锁不解决线程间同步，只解决线程内重入；用它替代
std::mutex后，多个线程仍可同时进入同一临界区 - 检查点：如果代码里出现
std::recursive_mutex却没有对应std::recursive_mutex::lock()的嵌套调用逻辑，基本就是误用
std::timed_mutex 在超时分支里漏掉错误处理
用 try_lock_for() 是为了防死锁，但很多人只写了成功路径，把超时当“小概率事件”忽略。
立即学习“C++免费学习笔记（深入）”；
- 现象：系统负载高时偶发逻辑错，比如订单状态被跳过更新、缓存未刷新却返回旧值
- 关键点：
try_lock_for()返回false时，你得决定是重试、降级、还是直接返回错误——不能假装它没发生 - 常见错误：在 if 分支里处理了加锁成功，却在 else 里什么也不做，导致后续操作在无锁状态下执行
自定义 RAII 锁包装器没声明 noexcept
如果封装了 std::lock_guard 或 std::unique_lock 的 wrapper，并在析构函数里抛异常（比如日志失败 throw），那它就不满足 RAII 安全前提。
- 现象：线程在临界区末尾意外终止，锁没释放，其他线程永久阻塞；或者异常传播导致栈展开时二次崩溃
- 必须加
noexcept：所有 RAII 锁类的析构函数都应标记为noexcept，否则编译器可能拒绝优化，运行时行为不可控 - 验证方式：在析构函数里加
static_assert(std::is_nothrow_destructible_v<mylockguard>)</mylockguard>
逻辑错最难调试，因为它不报错、不中断、甚至不 crash；最容易被忽略的是锁的语义匹配——不是“能不能锁住”，而是“锁住后是否真能保证你要的同步效果”。
