CMAKE_BUILD_TYPE仅在单配置生成器（如Ninja、Makefiles）中有效，需显式传入（如cmake -B build -DCMAKE_BUILD_TYPE=Debug）才非空；在VS等多配置生成器中该变量恒为空，应使用$<CONFIG:Debug>等生成器表达式进行配置区分。
cmake -B build -DCMAKE_BUILD_TYPE=Debug 时 CMAKE_BUILD_TYPE 才有值
单配置生成器（如 Ninja、Unix Makefiles）下，CMAKE_BUILD_TYPE 是你手动传入的变量，不是自动检测的。不传就为空，传了才生效。常见错误是写 if(CMAKE_BUILD_TYPE STREQUAL "Debug") 却没在命令行指定，结果条件永远不成立。
正确做法是：构建前必须显式指定，比如：
cmake -B build -DCMAKE_BUILD_TYPE=Debug cmake -B build -DCMAKE_BUILD_TYPE=Release
注意：CMAKE_BUILD_TYPE 在 Visual Studio 这类多配置生成器中始终为空，此时不能依赖它做判断——这点容易被忽略，后续会讲。
target_compile_definitions 怎么只对 Debug 生效
用 target_compile_definitions 加宏时，如果直接写 target_compile_definitions(myapp PRIVATE DEBUG)，这个宏会在所有构建类型里都定义，起不到区分作用。
推荐写法（CMake 3.19+）：
target_compile_definitions(myapp PRIVATE $<CONFIG:Debug>:DEBUG $<CONFIG:Release>:NDEBUG )
说明：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
$<CONFIG:Debug>是 generator expression，只在 Debug 配置下展开 - 它兼容所有生成器（包括 VS 和 Ninja），比
if(CMAKE_BUILD_TYPE...)更可靠 - 避免在全局 scope 用
add_definitions，否则宏污染所有 target
Debug 和 Release 下链接不同的库（Windows VCRT）
Windows 上 debug 版运行库带 d 后缀（如 msvcrtd.lib），release 版不带（msvcrt.lib）。硬编码会导致链接失败或运行时崩溃。
正确方式是用 debug / optimized 关键字：
target_link_libraries(myapp PRIVATE debug msvcrtd.lib optimized msvcrt.lib )
原理：
- CMake 在生成链接命令时，会根据当前构建配置自动选一个
- 不用判断
CMAKE_BUILD_TYPE，也不用写 if-else - 该语法在所有生成器下都有效，VS、Ninja、Xcode 全支持
Visual Studio 项目里怎么让 Debug/Release 区分得清清楚楚
VS 生成器不设 CMAKE_BUILD_TYPE，但会把所有配置列在 CMAKE_CONFIGURATION_TYPES 里（通常是 Debug;Release;RelWithDebInfo;MinSizeRel）。这时候靠 if(CMAKE_BUILD_TYPE...) 就完全失效。
两个务实方案：
- 用
$<CONFIG:...>generator expression —— 它在 VS 里照样解析，且更精准 - 给输出文件加后缀，避免混淆：
set_target_properties(myapp PROPERTIES DEBUG_POSTFIX "_d")，这样 Debug 版生成myapp_d.exe，Release 版还是myapp.exe
关键点：VS 的配置切换发生在构建阶段（build time），不是配置阶段（configure time），所以所有条件逻辑必须能延迟到构建时求值 —— 只有 generator expression 做得到。
