cmakedeps生成xxx-config.cmake文件供find_package(config)发现库，但需配合cmaketoolchain确保abi一致，并手动用target_link_libraries链接；路径、构建类型须严格对齐，否则链接失败。
Conan CMakeDeps 生成的文件让 find_package 能找到 Conan 安装的库
CMake 默认不认 Conan 下载的包，find_package(fmt CONFIG REQUIRED) 会失败，除非你手动把路径塞进 CMAKE_PREFIX_PATH。CMakeDeps 的作用就是自动生成 fmt-config.cmake、spdlog-config.cmake 这类文件，并放在 CMake 能自动扫描到的位置（比如 ${CMAKE_BINARY_DIR}/generators/），让 find_package 像查系统安装的 OpenCV 那样直接命中。
CMakeDeps 不等于自动链接，target_link_libraries 仍需手动写
它只解决「发现」问题，不解决「链接」问题。即使 find_package(fmt CONFIG REQUIRED) 成功了，你也得显式调用 target_link_libraries(myapp PRIVATE fmt::fmt) —— 否则编译器根本不会把 fmt 的头文件和库加进去。常见错误是只写了 find_package 就以为万事大吉，结果报 fmt::format 未声明。
-
fmt::fmt是 CMakeDeps 生成的 IMPORTED INTERFACE target，必须用双冒号语法 - 如果依赖有 COMPONENTS（如
spdlog::spdlog_header_only），得确认 conanfile.txt 里是否启用了对应选项（比如spdlog:header_only=True） - 生成的 target 名称严格遵循
<pkgname>::<targetname></targetname></pkgname>，大小写敏感，fmt::Fmt或FMT::fmt都会失败
CMakeDeps 依赖 CMakeToolchain 才能正确传递编译设置
如果你只用 CMakeDeps，但没用 CMakeToolchain，很可能遇到 ABI 不匹配：比如 Conan 用 std=c++17 编译的 spdlog，而你的项目默认是 C++14，链接时出现 undefined reference。CMakeToolchain 负责把 Conan 的 compiler.cppstd、compiler.libcxx 等设置透传给 CMake，确保两边一致。
- 必须在
CMakeLists.txt开头就include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake)，顺序不能错 -
conan install命令里没加--output-folder=build，conan_toolchain.cmake可能生成在错误位置，导致 include 失败 - CMakeDeps 生成的 config 文件里硬编码了库路径，所以
conan install和cmake ..必须在同一个 build 目录下执行，跨目录挪动会断链
CMakeDeps 对多配置构建（Debug/Release）的支持很弱
它默认按当前 build_type 生成一套配置，也就是说你在 Release 模式下运行 conan install，生成的 fmt-config.cmake 里只会包含 Release 版本的库路径。如果之后切到 Debug 模式构建，find_package 仍会加载 Release 的配置，链接时大概率失败。
- 解决办法是：对每个 build_type 单独建子目录，比如
build/Release和build/Debug，分别运行conan install - 不要试图在一个 build 目录里混用不同
build_type，CMakeDeps 不支持这种场景 - 若项目必须单目录多配置（如 Visual Studio 的 Multi-Config Generator），建议换用
conanfile.py+self.cpp_info自定义逻辑，或改用 vcpkg
