MSVCP依赖指程序因使用动态C++运行时（/MD）而需MSVCP140.dll等系统DLL；改用/MT静态链接可消除，但须确保所有依赖库、Windows SDK组件及第三方代码均统一静态编译，否则仍会隐式引入动态依赖。
什么是MSVCP依赖，为什么它会出现
当你用MSVC编译C++程序，默认链接的是动态运行时（/MD），这会让可执行文件依赖MSVCP140.dll（或MSVCP140D.dll调试版）等系统级DLL。这些DLL属于Visual C++ Redistributable，目标机器若未安装对应版本，程序直接启动失败，报错类似The program can't start because MSVCP140.dll is missing。
静态链接运行时（即把libcmt.lib、libcpmt.lib等直接打进EXE）能彻底消除该依赖，但必须同步处理C和C++两套运行时，且影响异常处理、线程局部存储等行为。
/MT 和 /MTd 是关键开关，但光改它还不够
在MSVC项目属性中将“C/C++ → 代码生成 → 运行时库”设为/MT（Release）或/MTd（Debug），只是第一步。常见疏漏包括：
- 第三方库（如Boost、OpenSSL、fmt）本身是用
/MD编译的，链接时会偷偷拉入动态运行时符号，导致最终EXE仍依赖MSVCP140.dll - CMake项目中，
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded")必须全局生效，否则子模块可能回退到/MD - 使用
#pragma comment(lib, "...")硬编码链接某lib时，若该lib是动态版，会覆盖/MT设置 - Windows SDK头（如
winsock2.h）隐式引入ws2_32.lib，它不带运行时依赖，但若你手动加了legacy_stdio_definitions.lib等，需确认它也是静态版
验证是否真正消除了MSVCP依赖
不能只看链接器输出“LNK4098”，要实测。推荐两个轻量方法：
立即学习“C++免费学习笔记（深入）”；
- 用
dumpbin /dependents your.exe查看输出中是否还有MSVCP140.dll、VCRUNTIME140.dll——只要出现任一，说明没干净 - 在一台干净的Windows（未装VS或VC++ Redist）上双击运行，同时用Process Monitor监控DLL加载行为；若看到
NAME NOT FOUND对MSVCP140.dll的尝试，且程序仍正常启动，才算成功 - 注意：即使用了/MT，若代码里调用了
std::filesystem（VS2019+），它底层仍可能通过延迟加载间接依赖VCRUNTIME140.dll，这是已知限制，无法完全规避
静态链接后要注意的兼容性陷阱
/MT不是银弹，它改变内存管理模型和全局状态隔离方式：
- 不同DLL若各自静态链接运行时，它们之间的
new/delete不能跨边界配对——比如DLL A里new的内存，不能在EXE（/MT）里delete，否则crash -
std::thread、std::mutex在/MT下仍可用，但若DLL和EXE混用/MD与/MT，线程局部变量（thread_local）可能行为异常 - 某些Windows API（如
FormatMessage）返回的字符串若用std::string接收，在/MT下不会出问题；但若DLL用/MD导出一个返回std::string的函数，EXE用/MT调用，就可能因分配器不一致而崩溃
真正零依赖的静态运行时方案，只适用于纯EXE、无第三方DLL、且所有依赖库都重新用/MT编译的场景。稍有不慎，反而比留着MSVCP依赖更难诊断。
