cmake中public、private、interface决定依赖是否向下游传播：private仅当前目标使用且不传播，public使当前目标及所有下游目标继承依赖，interface要求下游目标必须链接而当前目标不链接。
要让CMake正确传递头文件路径、编译定义和链接库，必须搞清PUBLIC、PRIVATE、INTERFACE在target_link_libraries等命令中的实际行为——它们不是语义标签，而是决定依赖是否向下游传播的开关。
先看一个典型错误场景
你写了一个静态库libmath，它的头文件math.h里直接用了<cmath></cmath>，而源文件math.cpp还额外链接了系统数学库m。如果用target_link_libraries(libmath PRIVATE m)，下游可执行程序链接libmath时会编译失败：找不到sqrt等符号。
因为PRIVATE只告诉CMake“libmath自己要连m”，但不告诉编译器“调用libmath的代码也需要看到m提供的符号声明”。这一步错，整个依赖链就断在编译期。
三种作用域的本质区别
PUBLIC、PRIVATE、INTERFACE不是并列选项，而是从“谁用”和“谁传”两个维度交叉定义的：
① PRIVATE：当前目标需要，且不向任何下游目标暴露。适用于仅在.cpp中调用、头文件完全不涉及的依赖。比如日志库spdlog只在libnetwork的实现里打日志，头文件里没它，就用PRIVATE。
② PUBLIC：当前目标需要，且所有链接它的目标也自动继承该依赖。适用条件是：头文件中直接或间接包含了被依赖库的头文件。例如libjson的json.hpp里#include
③ INTERFACE：当前目标自己不链接，但所有链接它的目标必须链接。典型用于纯头文件库（header-only）——它没有.o文件，但别人用它时必须有对应依赖。比如Eigen库本身不编译，但你的libvision用了Eigen头文件，就得INTERFACE链接Eigen。
不同命令中作用域的实际效果
方法一：target_link_libraries
这是最常踩坑的地方。对可执行文件使用PUBLIC/INTERFACE等同于PRIVATE，因为可执行文件没有“下游”；但对库目标，三者行为截然不同：
• PRIVATE m → libA连m，libB链接libA时看不到m，运行时若libA内部调用m函数，libB加载后可能报undefined symbol
• PUBLIC m → libA连m，libB链接libA时自动获得m的链接项和头文件路径（如果m通过target_include_directories设了PUBLIC）
• INTERFACE m → libA不连m，但libB链接libA时强制连m；libA自己编译会失败（除非m确实是纯头文件）
CMake 4.3.2 Windows x86_64 历史版本安装包，适合旧项目兼容、构建环境回退、CMakeLists.txt 迁移验证、Visual Studio/Ninja/Makefile 生成器测试和 C/C++ 项目维护。
【INTERFACE链接的库必须确保调用方能独立完成链接，否则构建直接中断】
方法二：target_include_directories
作用域决定头文件搜索路径如何传播：
PRIVATE include → 只有libA的源文件能#include "a.h"，libB链接libA后不能访问libA头文件里的#include "a.h"
PUBLIC include → libA自己能用，libB链接libA后也能顺着include路径找到a.h
INTERFACE include → libA自己不用这些头文件，但libB链接libA后，编译器会把include加进libB的-I参数里
方法三：target_compile_definitions
宏定义的可见性直接影响条件编译逻辑：
PRIVATE ENABLE_LOG → 只有libA的.cpp里#ifdef ENABLE_LOG会生效
PUBLIC ENABLE_LOG → libA和所有链接libA的目标都能看到这个宏
INTERFACE ENABLE_LOG → libA不感知该宏，但libB链接libA后，其编译单元自动定义ENABLE_LOG
