优先使用 target_compile_options 和 target_compile_definitions，因其作用域明确、支持 PUBLIC/PRIVATE/INTERFACE 语义，避免全局污染和多目标维护难题；CMAKE_CXX_FLAGS 全局拼接、不区分构建类型、难管控继承，易引发冲突与误配。
直接说结论：优先用 target_compile_options 和 target_compile_definitions，而不是改 CMAKE_CXX_FLAGS；全局设置只在极简项目里凑合用，一上多目标就容易漏、难维护。
为什么不能无脑 set(CMAKE_CXX_FLAGS)？
这个变量是“全局拼接式”的，所有 target 都会继承它，但你没法控制谁该用、谁不该用。比如你给整个项目加了 -Werror，结果某个第三方子模块自带 warning，构建直接失败——你得去 patch 它，或者绕路 disable 全局 flag，非常被动。
更麻烦的是，CMAKE_CXX_FLAGS 本身不区分 build type（Debug/Release），你得手动配 CMAKE_CXX_FLAGS_DEBUG 和 CMAKE_CXX_FLAGS_RELEASE，稍一疏忽就导致 Debug 版没调试符号、Release 版没优化。
- 它不随 target 生命周期管理，删 target 时 flag 不自动清理
- 和
add_subdirectory引入的外部项目容易冲突 - 无法表达“仅对库 A 开启
-fPIC，对可执行文件 B 关闭”这类细粒度需求
target_compile_options 怎么写才安全？
这是 CMake 2.8.12+ 推荐方式，把编译选项绑定到具体 target 上，语义清晰、作用域明确。
关键点是权限修饰符：PUBLIC 表示“本 target 用 + 所有链接它的 target 也继承”，PRIVATE 表示“只本 target 用”，INTERFACE 表示“本 target 不用，但链接它的必须用”。
- 对可执行文件，基本都用
PRIVATE：target_compile_options(myapp PRIVATE -Wall -Wextra -O2) - 对库，若希望调用方也受约束（比如强制要求 C++17），用
PUBLIC：target_compile_options(mylib PUBLIC -std=c++17) - 若只是内部实现需要（比如用
-fvisibility=hidden控制符号导出），用PRIVATE - 避免混用：
target_compile_options(mylib PUBLIC -DFOO PRIVATE -g)是合法的，但建议拆成两条更易读
如何兼容不同编译器加不同 flag？
别硬写 if(MSVC) 判断，CMake 提供了更健壮的方式：check_cxx_compiler_flag + 条件式添加。
例如想加 -fsanitize=address，但只在支持的编译器上启用：
include(CheckCXXCompilerFlag)
check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORTS_ASAN)
if(COMPILER_SUPPORTS_ASAN)
target_compile_options(myapp PRIVATE -fsanitize=address -fno-omit-frame-pointer)
endif()
- 直接写
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU" OR CMAKE_CXX_COMPILER_ID STREQUAL "Clang")看似简单，但 ID 值依赖 CMake 版本，且不覆盖 ICC、AppleClang 等变体 -
check_cxx_compiler_flag是运行时探测，比静态判断更可靠 - 注意：该函数需在
project()之后、add_executable()之前调用
宏定义该用 add_definitions 还是 target_compile_definitions？
一律用 target_compile_definitions。前者是全局污染型，后者绑定 target，且支持 PUBLIC/PRIVATE/INTERFACE 语义。
比如要为测试可执行文件开启调试宏：
target_compile_definitions(test_app PRIVATE ENABLE_LOG=1 DEBUG_LEVEL=3)
-
add_definitions(-DENABLE_LOG=1)会让所有后续 target（包括第三方库）都定义该宏，极易引发命名冲突 -
target_compile_definitions支持赋值语法（ENABLE_LOG=1），而add_definitions只能写-DENABLE_LOG=1，多一个破折号，少一分确定性 - CMake 3.12+ 已标记
add_definitions为 deprecated，新项目别碰
真正容易被忽略的点是：编译选项和宏定义的传递性（PUBLIC vs PRIVATE）必须和头文件包含路径（target_include_directories）保持一致。比如你用 PUBLIC 暴露了 -DUSE_SSL，但没用 PUBLIC 暴露 OpenSSL 头路径，链接方照样编译不过——这两件事从来不是孤立的。
