这类崩溃本质是CRT运行时库混用导致的符号冲突或内存管理不一致，关键看LNK2038/LNK2005错误及“RuntimeLibrary”字样，需确保所有模块统一使用/MD或/MT。
这类崩溃本质是链接阶段埋下的隐患，到运行时才暴露——不是代码逻辑错，而是模块间运行时库（CRT）“说的不是同一种语言”。关键要识别出是 /MT 和 /MD 混用导致的符号冲突或内存管理不一致。
看错误日志里有没有“RuntimeLibrary”字样
这是最直接的信号。编译或链接时如果出现类似下面的提示，基本可以锁定问题：
- error LNK2038: 检测到“RuntimeLibrary”的不匹配项：值“MD_DynamicRelease”不匹配值“MT_StaticRelease”
- LNK2005: 已经在 xxx.obj 中定义 _malloc、_free、_beginthreadex 等 CRT 符号
- 程序启动后不久就崩溃，堆栈里看不到你的业务代码，而是卡在
__dllonexit、initterm或内存分配函数中
检查所有参与构建的模块是否统一使用 /MD 或 /MT
静态库（.lib）、动态库（.dll）、主工程，三者必须一致。常见陷阱包括：
- 你自己项目设了
/MD，但引用的第三方 .lib 是用/MT编译的（比如某些预编译的 OpenCV、gRPC、abseil） - CMake 项目中，
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreadedDLL")没全局生效，部分子模块仍走默认静态 - Qt 官方二进制包默认用
/MD，但你项目误配成/MT，导致 Qt 对象析构时调用的free和你 main 程序用的free不是同一个内存池
用 dumpbin 或 Dependency Walker 验证实际依赖
在 Windows 下，对生成的 .exe 或 .dll 执行：
-
dumpbin /directives your_app.exe | findstr "DEFAULTLIB"—— 查看它期望链接哪些 CRT 库（如MSVCRT.lib对应 /MD，LIBCMT.lib对应 /MT） - 用 Dependency Walker 打开可执行文件，观察是否混杂加载了
msvcp140.dll（/MD）和试图静态链接 CRT 的行为 - 若发现同时依赖
ucrtbase.dll和msvcr120.dll等多个运行时 DLL，也说明配置混乱
运行时表现：崩溃点往往在对象构造/析构或跨模块内存操作
典型现场包括：
- new 出的对象传给另一个模块 delete，结果触发访问冲突（因为 new 和 delete 调用的堆管理器不同）
- Qt 的
QObject子类析构时崩溃在QMetaObject::activate内部，实际是信号槽连接表内存被错误释放 - std::string 或 std::vector 在 DLL 边界传递后内容乱码或崩溃，根源是 STL 容器内部缓冲区由不同 CRT 分配
