VS2022 Release 模式下 std::mutex 加锁崩溃

问题现象

在测试程序时，发现一处崩溃：

1	std::lock_guard<std::mutex> lock(m_mutex);

排查

由于崩溃发生在加锁位置，最开始怀疑是：

mutex 对象已析构
空指针或野指针访问
多线程竞争导致内存破坏

随后逐项验证：

检查对象生命周期，确认 mutex 仍然有效
检查线程创建与退出流程，没有发现异常
使用最小化 Demo 复现问题

最小化 Demo 显示，std::mutex::lock() 必现崩溃，说明是 STL 内部崩溃，业务代码没有明显异常。

此外还有个有趣的现象：

环境	结果
VS2019 Debug	正常
VS2019 Release	正常
VS2022 Debug	正常
VS2022 Release	崩溃

原因分析

阶段	Debug	Release
编译器	cl.exe (VS2019/VS2022)	cl.exe (VS2019/VS2022)
链接库	libcpmtd.lib / msvcprtd.lib	libcpmt.lib / msvcprt.lib
运行库 DLL	msvcp140d.dll / vcruntime140d.dll	msvcp140.dll / vcruntime140.dll
来源	Visual Studio 安装目录	VC Redistributable

关键区别在于：Debug 版的运行库 DLL 来自 Visual Studio 安装目录，随 VS 一同更新；而 Release 版加载的是系统中独立安装的 Visual C++ Redistributable。

因此：

VS2022 编译阶段使用的是新版 STL 和新版工具链
但程序启动后实际加载的是系统中旧版本的 Visual C++ Redistributable

编译期与运行期的版本不匹配，导致了崩溃。

解决方法

排查系统 msvcp140.dll / vcruntime140.dll，发现是12.x

升级运行库为14.x：

Microsoft Visual C++ Redistributable 2015-2022

升级完成后重启系统再尝试，崩溃消失。

总结

这类问题有几个典型特征：

Debug 正常，Release 崩溃
旧版本VS 正常，新版本VS 崩溃
崩溃点位于 STL 内部

遇到此类问题时，除了检查代码本身，也建议优先排查：

VC Runtime 版本
DLL 版本冲突
ABI 兼容性问题
第三方库编译器版本差异

VS2015、VS2017、VS2019、VS2022 使用统一的 MSVC Runtime（14.x 系列），理论上二进制兼容；但目标机器仍需要安装足够新的 Visual C++ Redistributable。
新版工具链生成的程序运行在过旧 Runtime 上时，仍可能出现 STL、线程库或运行时相关的异常。