Visual Studio项目结构由构建方式和依赖关系决定，.vcxproj仅记录参与编译的文件而不约束目录层级；真正影响结构的是预编译头使用、模块划分、DLL导出、外部构建系统对接等因素，强行套用模板反而阻碍后期重构。
项目结构不是靠“设计”出来的，而是被构建方式和依赖关系决定的
Visual Studio 本身不强制代码结构，vcxproj 文件只记录哪些 .cpp 和 .h 文件参与编译，不规定目录层级。真正影响结构的是：你用不用预编译头、是否分模块（如 core / gui / net）、要不要导出 DLL 符号、是否对接 CMake 或外部构建系统。强行套“标准目录模板”反而容易在后期重构时卡住。
从空项目开始搭结构，比改模板更可控
选「空项目」模板，而不是「控制台应用」——后者会自动生成 main.cpp 和预编译头 stdafx.h（或 pch.h），还默认开启 /Yu 编译选项，后续想拆模块时经常因头文件包含顺序报错。
- 右键「源文件」→「添加」→「新建项」，手动建
src/main.cpp、src/core/log.cpp、include/core/log.h等，路径名直接体现逻辑分层 - 在「属性页」→「C/C++」→「常规」→「附加包含目录」中填
$(ProjectDir)include，让所有#include "core/log.h"能直接解析 - 如果用了 CMake，就别在 VS 里手动加文件；VS 会读
CMakeLists.txt，此时结构由add_library()和target_include_directories()定义
头文件组织最容易踩的三个坑
VS 的「头文件」虚拟文件夹只是 IDE 显示用，不影响编译。但实际路径错位会导致 #include 失败或重复定义，尤其多人协作时。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
#pragma once比#ifndef XXX_H更省心，但不能跨文件系统（比如 WSL 共享目录），CI 构建失败常源于此 - 第三方库头文件别硬塞进项目目录，统一放
third_party/boost，然后在「附加包含目录」里加$(ProjectDir)third_party，避免 git 提交二进制或版本混杂 - 导出 DLL 接口时，
__declspec(dllexport)必须出现在声明处（.h），且该头文件必须能被调用方直接#include到——这意味着它的路径不能依赖相对跳转，得靠「附加包含目录」兜底
多项目共存时，解决方案层级比单个项目结构更重要
一个 .sln 可含多个 .vcxproj（如 MyApp.exe + MyLib.lib + Tests.dll），这时结构重心要从“文件怎么放”转向“项目之间怎么引用”。
立即学习“C++免费学习笔记（深入）”；
- 右键解决方案 →「添加」→「现有项目」，把
MyLib.vcxproj加进来，再右键MyApp→「项目依赖项」勾上MyLib，VS 才会在构建顺序和链接器参数中自动处理 - 不要用「相对路径」在
#include中跨项目引用头文件（如#include "../../MyLib/include/api.h"），应统一用「引用」+「附加包含目录」，否则换机器或 CI 就断 - Debug/Release 配置需对齐：若
MyLib是Multi-threaded Debug DLL (/MDd)，MyApp也必须是，否则链接时报LNK2038: mismatch detected for 'RuntimeLibrary'
结构最终服务于可维护性，而不是视觉整齐。很多团队卡在“头文件找不到”或“LNK2019”上，其实问题不在目录名，而在 vcxproj 里没配对好 AdditionalIncludeDirectories 和 AdditionalDependencies 这两个字段。
