std::shared_mutex仅C++17及以上可用，需显式启用标准；读锁用shared_lock、写锁用unique_lock，不可混用或误配lock_guard；不支持deferred构造和try_lock成员函数；性能未必优于mutex，且不支持递归锁与condition_variable。
std::shared_mutex在C++17才正式可用，别在旧标准下硬用
如果你的编译器默认不启用C++17或更高版本，std::shared_mutex 会直接报错：‘shared_mutex’ is not a member of ‘std’。GCC需加 -std=c++17，Clang同理；MSVC 2015 Update 3起支持，但必须开启 /std:c++17 或更高。用 __cplusplus 宏检查时注意：MSVC的宏值不可靠，建议优先查编译器文档而非依赖宏判断。
读锁用shared_lock，写锁用unique_lock，不能混用
std::shared_mutex 不支持直接构造 std::lock_guard 或 std::scoped_lock —— 这俩只适配独占语义。读操作必须用 std::shared_lock<:shared_mutex></:shared_mutex>，写操作必须用 std::unique_lock<:shared_mutex></:shared_mutex>。常见错误是把 shared_lock 用于写场景，导致编译失败或逻辑错误（如静默降级为独占锁却没意识到）。
示例片段：
std::shared_mutex rw_mutex; std::shared_lock<std::shared_mutex> read_lock(rw_mutex); // ✅ 正确读锁 std::unique_lock<std::shared_mutex> write_lock(rw_mutex); // ✅ 正确写锁 // std::lock_guard<std::shared_mutex> bad(rw_mutex); // ❌ 编译失败
shared_lock不支持deferred构造，unique_lock可以但要小心
std::shared_lock 的构造函数没有 std::defer_lock 重载，它总是立即尝试获取共享锁。而 std::unique_lock 支持延迟加锁，但若后续调用 lock() 失败（比如被中断），它会抛出 std::system_error。实际使用中，如果需要条件性加写锁，应捕获异常或改用 try_lock()：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
write_lock.try_lock()返回bool，失败时不抛异常，适合非阻塞场景 -
read_lock没有对应try_lock成员函数，只能用std::shared_lock(mutex, std::try_to_lock)构造 - 混合使用
try_to_lock和defer_lock时，务必确认 mutex 当前无持有者，否则行为未定义
性能敏感场景下，shared_mutex可能比mutex更慢
不是所有“读多写少”场景都适合 std::shared_mutex。它的实现通常依赖 futex 或内核同步原语，在低争用时开销高于 std::mutex；高争用下，共享锁的唤醒机制（如多个 reader 同时释放）也可能引入调度抖动。实测发现：单核环境或临界区极短时，std::shared_mutex 反而降低吞吐量。建议先用 std::mutex 基线测试，再对比 std::shared_mutex + shared_lock 的真实压测数据。
另外，std::shared_mutex 不支持递归锁，也不支持与 std::condition_variable 配合 —— 这些限制容易在迁移旧代码时被忽略。
