conan项目目录结构的关键在于配置文件位置与构建目录隔离性：conanfile.txt必须与cmakelists.txt同级；build目录须独立于src/conan等源码目录；test_package/仅打包时需与conanfile.py同级。
Conan 项目目录组织没有强制标准，但错误的结构会导致 conan install 找不到配置、CMakeLists.txt 无法加载生成文件、或跨平台构建时路径错乱。关键不是“放哪里”，而是“谁读谁、怎么读、读什么”。
conanfile.txt 必须和 CMakeLists.txt 在同一级目录
这是最常踩的坑：很多人把 conanfile.txt 放进 conan/ 子目录，结果 conan install .. 执行时找不到它，或者 CMakeDeps 生成的 fmt-config.cmake 路径被算错。
-
conan install默认只在当前工作目录找conanfile.txt；它不递归搜索 -
CMakeDeps生成的文件默认放在${CMAKE_BINARY_DIR}/generators/，而include()语句里写的路径必须和实际位置匹配 - 如果
CMakeLists.txt和conanfile.txt不同级，include(${CMAKE_CURRENT_LIST_DIR}/build/Release/generators/conan_toolchain.cmake)这类写法极易失效
build/ 目录必须是独立的，且不能嵌套在 src/ 或 conan/ 下
Conan 的 --build=missing 和 CMake 的 out-of-source 构建都依赖 build 目录完全隔离。混在源码里会导致缓存污染、权限问题，甚至 macOS 上因 Spotlight 索引引发构建失败。
- 推荐在项目根目录执行：
mkdir build && cd build && conan install .. -s build_type=Release - 不要用
build/作为conanfile.txt的父目录（即build/conanfile.txt是错的） - 不同平台建议用不同 build 子目录，比如
build-linux、build-win-msvc，避免 CMake 缓存和 Conan toolchain 文件互相覆盖
test_package/ 目录要和 conanfile.py 同级（仅限创建包场景）
如果你在打包自己的库（而非只是消费依赖），test_package/ 是验证包是否可用的关键。它的位置不对，conan create . 就不会运行测试程序。
-
test_package/必须与conanfile.py处于同一目录下（不是conanfile.txt） -
test_package/conanfile.py中的requires = "mylib/1.0"会自动解析为当前正在创建的包，前提是目录结构合规 - 若只想消费依赖（如你的项目只是用
spdlog），根本不需要test_package/目录
真正容易被忽略的是：Conan 不关心你源码怎么放，但它对「配置文件位置」和「构建目录隔离性」极其敏感。哪怕只差一级目录，find_package(fmt CONFIG REQUIRED) 就可能报 Could not find fmtConfig.cmake —— 问题不在库本身，而在 conan install 输出路径和 CMakeLists.txt 中 include() 的路径没对齐。
