find_package 不区分 Debug/Release，需手动用 FIND_LIBRARY 分别获取两版本路径，并在 target_link_libraries 中用 debug/optimized 关键字显式指定；否则易致 LNK2038 或运行时崩溃。
直接结论：find_package 本身不区分 Debug/Release，必须靠后续 target_link_libraries 显式指定，且依赖你提前用 FIND_LIBRARY 分别找到两个版本的库文件路径。
为什么 find_package 不自动区分 Debug 和 Release 库
find_package 的职责是「定位库」，不是「按构建类型链接」。它调用的 FindXXX.cmake 或 XXXConfig.cmake 脚本，通常只返回一个库路径（比如 XXX_LIBRARY），默认倾向 Release；即使你传了 CONFIG 模式，多数第三方 Config 脚本也只提供一套导入目标（如 xxx::xxx），不拆分 debug/release 变体。
Windows 上常见的 calc.lib / calcD.lib、VCRT 的 msvcrt.lib / msvcrtd.lib 这类命名差异，find_package 不会主动识别或切换——它没这个逻辑。
- 它不会读取
CMAKE_BUILD_TYPE去决定该找哪个后缀 - 它不会根据当前构建配置动态重选库路径
- 如果你只调用一次
FIND_LIBRARY(calc_LIBRARY calc.lib ...)，那calc_LIBRARY变量就固定了，Debug 构建时照样链接 Release 库，大概率报 LNK2038 或运行时崩溃
正确做法：手动分离 FIND_LIBRARY + target_link_libraries 区分
核心就是两步：先分别找到两个路径，再在链接时用 debug / optimized 关键字绑定。
以 Windows 下查找 calc 库为例：
# 在 Findcalc.cmake 或主 CMakeLists.txt 中
FIND_PATH(calc_INCLUDE_DIR icalc.h ${CMAKE_CURRENT_SOURCE_DIR}/ext/calc/include)
FIND_LIBRARY(calc_LIBRARY_release calc.lib ${CMAKE_CURRENT_SOURCE_DIR}/ext/calc/lib/release)
FIND_LIBRARY(calc_LIBRARY_debug calcD.lib ${CMAKE_CURRENT_SOURCE_DIR}/ext/calc/lib/debug)
<h1>必须检查两者都存在，否则构建会失败</h1><p>if(NOT calc_INCLUDE_DIR OR NOT calc_LIBRARY_release OR NOT calc_LIBRARY_debug)
message(FATAL_ERROR "calc: missing include or library (debug/release)")
endif()</p><h1>导入头文件</h1><p>target_include_directories(${PROJECT_NAME} PRIVATE ${calc_INCLUDE_DIR})</p><h1>关键：链接时显式区分</h1><p>target_link_libraries(${PROJECT_NAME} PRIVATE
debug ${calc_LIBRARY_debug}
optimized ${calc_LIBRARY_release}
)
</p>
-
debug关键字仅对 Debug 构建生效，此时链接${calc_LIBRARY_debug} -
optimized关键字覆盖 Release / RelWithDebInfo / MinSizeRel 三种构建类型，链接${calc_LIBRARY_release} - 不要用
general，它会无条件链接，失去区分意义
常见错误和坑
这些错误会导致 Debug 构建链接 Release 库，或反过来，引发符号不匹配、CRT 冲突、LNK2038 等问题：
- 只写
target_link_libraries(${PROJECT_NAME} ${calc_LIBRARY})——${calc_LIBRARY}是单个变量，无法随构建类型变化 - 误以为
find_package(calc CONFIG)会自动选对库 —— 大多数 Config 脚本根本不处理 Debug/Release 分离 - 在
FIND_LIBRARY中混用路径，比如让calc_LIBRARY_release指向debug/目录 —— 路径写错比逻辑错更难排查 - 忘记
target_include_directories，导致 Debug/Release 下头文件不一致（例如宏定义不同） - 在多配置生成器（如 Visual Studio）下，
CMAKE_BUILD_TYPE为空 —— 此时debug/optimized仍有效，但不能依赖${CMAKE_BUILD_TYPE}做 if 判断
最易被忽略的一点：debug 和 optimized 是 CMake 链接器关键字，不是字符串，不能拼进变量名里；也不能用 if(CMAKE_BUILD_TYPE STREQUAL "Debug") 去包裹整个 target_link_libraries —— 这会导致 Release 构建时完全不链接该库。
