直接使用 std::mutex 即可，它已跨平台且可靠；仅在无 STL 的嵌入式环境等极少数场景才需绕过；需递归锁时用 std::recursive_mutex，需超时则用 std::timed_mutex 配合 RAII 封装。
用 std::mutex 就够了，别自己封装底层 API
绝大多数场景下，std::mutex 本身已是跨平台（Windows/Linux/macOS）且符合 C++11 标准的互斥锁实现，直接用它比手写封装更可靠。标准库背后已适配各平台原生机制（如 Windows 的 CreateMutex、Linux 的 pthread_mutex_t），你不需要、也不该重复造轮子。
常见错误是看到“跨平台”就立刻想封装 pthread_mutex_t 和 CRITICAL_SECTION —— 这反而引入兼容性风险：比如忘记在 Windows 上调用 InitializeCriticalSection，或 Linux 下漏掉 pthread_mutex_destroy，导致资源泄漏或崩溃。
- 只在极少数受限环境（如无 STL 的嵌入式裸机）才需绕过
std::mutex - 若项目强制要求 C++11 以下，优先升级编译器，而非自行实现
-
std::mutex不支持递归锁，需要时改用std::recursive_mutex
如何安全地封装成 RAII 类型（带超时/可移动）
真正值得封装的是使用方式，不是底层锁本身。比如加锁失败时阻塞太久、忘记解锁、或需要支持超时等待 —— 这些靠 std::unique_lock 和 std::timed_mutex 就能解决，无需重写锁逻辑。
一个典型需求：带超时的锁，失败时不抛异常而是返回 false。这时用 std::timed_mutex 配合 try_lock_for：
立即学习“C++免费学习笔记（深入）”；
class SafeTimedLock {
std::timed_mutex mtx_;
public:
bool try_lock_for(std::chrono::milliseconds ms) {
return mtx_.try_lock_for(ms);
}
void unlock() { mtx_.unlock(); }
};
-
std::timed_mutex在 Windows 和 POSIX 平台均被支持，但 macOS 早期版本（ - 不要给
SafeTimedLock加拷贝构造 —— 锁对象不可拷贝，否则编译报错：use of deleted function - 若需移动语义，显式声明
SafeTimedLock(SafeTimedLock&&)，但注意移动后原对象状态未定义，避免误用
多线程初始化和静态变量的坑
跨平台代码最容易栽在全局/静态 std::mutex 的初始化顺序上。C++11 规定静态局部 std::mutex 是线程安全的，但全局对象不是 —— 某些平台（尤其 Windows + MinGW）可能触发 DLL 加载时序问题，导致 std::mutex 构造函数被多次调用或未初始化。
- 永远用静态局部变量替代全局变量：
static auto& get_global_mutex() { static std::mutex m; return m; } - 避免在
main()之前（如全局对象构造函数里）调用lock()—— 此时std::mutex可能尚未完成初始化 - 若必须用全局锁，确保链接器设置正确：Windows 下加
/Zc:threadSafeInit-会禁用线程安全静态初始化，务必关闭
调试时怎么确认锁真的生效了
跨平台环境下，锁失效往往表现为偶发数据竞争，而非明显崩溃。不能只靠“没 crash 就没问题”。验证方法要具体：
- 用
std::atomic<int>计数器 + 多线程反复增减，配合TSAN（ThreadSanitizer）检测竞态 —— Clang/GCC 都支持，Windows 下可用 VS 的/fsanitize=thread - 在锁保护的临界区插入
std::this_thread::sleep_for(1ms)，放大争抢概率，更容易暴露死锁或未加锁访问 - Windows 上用
!locks命令（WinDbg）或 ETW 跟踪SRWLock（std::mutex在较新 MSVC 中实际使用它），Linux 用perf lock查看内核锁统计
跨平台锁的复杂点不在“怎么写”，而在“怎么验”—— 同一段代码在 macOS 上跑十次不崩，不代表没竞态；得用工具逼它出问题，才能确认封装真起作用。
