Windows下CMake多目录项目能跑通，关键在于add_subdirectory路径必须为相对路径且不带尾斜杠（如add_subdirectory(src)），头文件路径需通过target_include_directories(PUBLIC)传递而非include_directories，子目录CMakeLists.txt中禁止使用project()。
直接说结论：Windows 下 CMake 多目录项目能跑通，关键不在平台差异，而在 add_subdirectory 调用路径写法 和 头文件包含路径是否被正确传递到子目录。Windows 本身不额外制造障碍，但路径分隔符、大小写敏感性缺失、以及 Visual Studio 生成器对相对路径的解析习惯，会让某些在 Linux 下“碰巧能过”的写法在 Windows 上静默失败。
add_subdirectory 的路径必须是相对于当前 CMakeLists.txt 的相对路径，且不能带尾部斜杠
常见错误是写成 add_subdirectory(./src) 或 add_subdirectory(src/)，尤其在 Windows 上，部分 CMake 版本（如 3.18 之前）会把带斜杠的路径识别为绝对路径，导致找不到目录。正确写法只有：add_subdirectory(src)。
- 路径中不要出现
./、../（除非你真要跨级引用）、也不要加/结尾 - 子目录名区分大小写 —— Windows 文件系统不区分，但 CMake 解析时严格按字面匹配，
add_subdirectory(Src)和目录实际叫src就会报错Cannot find source directory - 如果子目录不存在，CMake configure 阶段就直接失败，不会等到 build 阶段
子目录里的 include_directories 默认不向上继承，得手动传或改用 target_include_directories
父目录写了 include_directories(include)，子目录的 add_executable 仍然找不到 include/common.h？这是最常踩的坑。因为 include_directories 是目录级作用域，不自动透传给子目录中定义的目标。
- 老写法（不推荐）：在每个子目录的
CMakeLists.txt里重复写include_directories(${PROJECT_SOURCE_DIR}/include) - 推荐写法：在父目录用
target_include_directories(mylib PUBLIC ${PROJECT_SOURCE_DIR}/include)，再让子目录的 target 通过target_link_libraries链接它，PUBLIC 属性会把头文件路径自动带过去 - 更干净的做法：子目录用
target_include_directories(myapp PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/../include)，明确指向根 include
Windows 下 MinGW/MSVC 对源文件路径的处理差异，影响 aux_source_directory 行为
aux_source_directory(src SRC_LIST) 在 Windows 上可能漏掉某些文件，尤其当 src 下有子目录（如 src/utils/）时 —— 它只扫一层，不递归。而且 MSVC 生成器对空格和中文路径更敏感，MinGW 则对反斜杠 \ 解析不稳定。
- 别依赖
aux_source_directory管理生产项目；它适合原型，不适合维护 - 真实项目请用
set(SRC_LIST src/main.cpp src/core/log.cpp src/utils/string.cpp)显式列出，或者用file(GLOB)（注意：GLOB 不自动 reconfigure，改了文件名需手动 touch CMakeLists.txt） - 路径统一用正斜杠
/，CMake 内部会自动适配 Windows；避免混用\和/
真正容易被忽略的是：子目录的 CMakeLists.txt 里不能写 project()。只要不是顶层入口，所有子目录的 CMakeLists.txt 都不该调用 project() —— 否则 CMake 会重置变量作用域、覆盖编译器设置，甚至让 ${CMAKE_CXX_STANDARD} 失效。这个错在 Windows + VS 生成器下表现得特别隐蔽：编译能过，但 C++17 的 std::optional 却报未声明。
