Additional Include Directories 和 Additional Library Directories 必须分开配置，因为前者供预处理器在 #include 时查找头文件（填父目录，如 C:\OpenCV\4.7.0\include），后者供链接器定位 .lib 文件（填目录，如 C:\OpenCV\4.7.0\lib），二者分属编译与链接不同阶段，路径类型、用途及语法要求均严格区分，不可混用。
Visual Studio 本身不提供像 CMake 或 vcpkg 那样的自动依赖解析能力，C++ 项目依赖关系必须手动配置、显式声明，且编译器和链接器不会帮你推导头文件或库的传递依赖。
为什么 Additional Include Directories 和 Additional Library Directories 必须分开配
这是两个独立阶段的搜索路径：前者供预处理器在 #include 时查找头文件，后者供链接器在 Additional Dependencies 中指定 .lib 名后，去定位实际的 .lib 文件位置。两者不能混用，也不能靠“把所有路径塞进一个框”来偷懒。
-
Additional Include Directories填的是头文件所在的**父目录**，比如C:\OpenCV\4.7.0\include，而不是C:\OpenCV\4.7.0\include\opencv2 -
Additional Library Directories填的是.lib所在的目录，如C:\OpenCV\4.7.0\lib；若填成C:\OpenCV\4.7.0\lib\opencv_world470.lib就会报错——它只接受目录，不接受文件路径 - 路径中含空格（如
C:\Program Files\）必须用双引号包裹，否则 MSVC 的命令行参数解析会截断
Additional Dependencies 里写什么、不写什么
这里只写 .lib 的**文件名（不含扩展名）**，例如 ws2_32.lib 写成 ws2_32 即可；但要注意：静态库（.lib）和动态库（.dll）的 .lib 是两类东西，前者是归档，后者是导入库，必须匹配你实际链接方式。
- 若用动态链接（默认），需确保运行时
.dll在PATH或可执行目录下，否则LoadLibrary失败或程序启动报“找不到指定模块” - 若用静态链接（如
/MT运行时），则Additional Dependencies中的.lib必须是静态版，且不能和动态版混链，否则LNK2005重复定义 - 第三方库常提供多个
.lib变体（debug/release、static/dynamic、x86/x64），务必与当前项目配置（Configuration+Platform）严格一致
用 .props 文件统一管理多项目依赖
直接在每个项目的属性页里填路径，不仅重复劳动，而且一旦路径变更（比如升级 OpenCV 版本），就得逐个改。更可靠的做法是提取成 .props 属性表，再通过属性管理器导入。
立即学习“C++免费学习笔记（深入）”；
- 新建
.props文件时，右键解决方案 → “属性管理器” → 展开对应配置（如Debug|x64）→ 右键 → “添加新项目属性表” - 在
.props中配置IncludePath和LibraryPath，并用用户宏（如$(MY_OPENCV_ROOT)）替代硬编码路径 - 团队协作时，把
.props提交到 Git，并在 README 中说明如何设置该宏（例如通过“工具 → 选项 → 项目和解决方案 → 用户宏”） - 注意：
.props的加载顺序影响覆盖行为——后加载的会覆盖先加载的同名属性，调试时可在“属性管理器”中拖动调整顺序
运行时 DLL 缺失错误怎么快速定位
编译通过但运行时报“找不到 libmysql.dll”或“无法启动此程序，因为计算机中丢失 libcrypto-3-x64.dll”，这类问题不是编译配置错，而是部署环节漏了动态库。
- 用
dumpbin /dependents your_app.exe查看程序真正依赖哪些 DLL（注意在开发机上运行，路径要指向生成的.exe） - 用
Dependencies.exe（开源工具）可视化依赖树，能直接标出缺失项和架构不匹配（x64 程序加载了 x86 DLL） - 不要把 DLL 直接丢进
System32——这是反模式；正确做法是：和.exe放同一目录，或加到应用启动前的PATH中 - 若用 vcpkg，启用
vcpkg integrate install后，它会自动注入Additional Dependencies和运行时 DLL 拷贝逻辑，但仅对 vcpkg 安装的库生效
最常被忽略的一点：C++ 项目没有“依赖图谱”的概念，所有依赖都靠人工维护。哪怕用了 .props，你也得自己确认头文件是否真被 #include 到、.lib 是否真被链接进、.dll 是否真在运行时可访问——没有中间层兜底，错一点就卡住。
