CMake是跨平台编译配置工具，通过CMakeLists.txt统一描述构建逻辑，借助cmake_minimum_required、project、add_executable等指令定义项目，利用WIN32/APPLE/UNIX等内置变量实现条件适配，并依赖CLion中正确配置的Toolchain完成多平台构建。
CLion 里没有“跨平台项目”模板，只有 CMake 驱动的项目
CLion 本身不提供所谓“跨平台项目”类型——它压根不关心你最终跑在 Windows、Linux 还是 macOS 上。真正决定跨平台能力的是 CMakeLists.txt 的写法和你选用的工具链。新建项目时选 C++ Executable 或 C++ Library 即可，后续所有跨平台适配都靠 CMake 控制。
常见错误现象：新建项目后直接在 Windows 下编译通过，一到 Linux 就报 std::filesystem 找不到、Qt 头文件路径错、或链接时缺 -lpthread。这些问题几乎全是因为 CMake 没声明标准、没查依赖、没设编译器选项。
- 必须显式设置 C++ 标准：
set(CMAKE_CXX_STANDARD 17)或更高（20更稳妥），否则不同平台默认标准不一致 - 用
find_package()查 Qt、Boost、OpenSSL 等依赖，别硬写include_directories()路径 - Windows 下注意 MSVC 和 MinGW 工具链差异：MSVC 不支持
__attribute__((visibility("default")))，MinGW 需要额外加set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)才能导出 DLL 符号
如何让同一个 CMakeLists.txt 在三平台都正常 build
关键不是“写三份配置”，而是用 CMake 内置变量做条件分支。CMake 自带 CMAKE_SYSTEM_NAME、CMAKE_SIZEOF_VOID_P、WIN32、APPLE、UNIX 等判断标识，比手写宏更可靠。
使用场景：比如你要链接线程库，在 Linux/macOS 是 -lpthread，Windows 下其实不需要；又比如资源文件路径分隔符，Windows 用 \，其他用 /，但 CMake 字符串操作天然支持正斜杠通用。
- 检测系统：
if(WIN32)/elseif(APPLE)/else()—— 注意APPLE不等于MACOSX，CMake 3.20+ 推荐用CMAKE_SYSTEM_NAME MATCHES "Darwin" - 路径处理统一用
file(TO_CMAKE_PATH "...")或直接写"/res/icon.png"，CMake 会自动转义 - 避免硬编码编译器标志：用
target_compile_features(mytarget PRIVATE cxx_std_17)替代add_compile_options(-std=c++17)，前者会自动补全缺失特性所需的 flag
CLion 的 Toolchain 设置直接影响跨平台可行性
很多人以为写好 CMake 就万事大吉，结果在 CLion 里点 Build 却提示 “No toolchain configured”。这是因为 CLion 的构建行为完全由当前激活的 Toolchain 决定，而一个 Toolchain 只绑定一种编译器+调试器+sysroot。
容易踩的坑：在 Windows 上装了 MSVC 和 MinGW，但 CLion 默认只选 MSVC；你写了 set(CMAKE_SYSTEM_NAME Linux)，却没配 WSL 或远程 Linux Toolchain，CLion 仍会尝试用本地 Windows 编译器去 build，必然失败。
- Windows 开发者想编译 Linux 目标：必须配 WSL2 Toolchain 或 Remote Host Toolchain，不能只改 CMake 变量
- macOS 上交叉编译 iOS？CLion 原生不支持，得用自定义 CMake generator + external build script
- Toolchain 切换后，务必点右下角
Reload CMake project，否则旧缓存还在，cmake --build实际执行的仍是上一次的配置
生成 DLL/SO/DYLIB 时最容易忽略的符号导出问题
跨平台动态库最常崩在符号不可见：Windows 下 DLL 导出函数要用 __declspec(dllexport)，Linux/macOS 下 SO/DYLIB 默认全局可见，但若用了 -fvisibility=hidden（很多项目为了减小体积会开），就必须显式标记 __attribute__((visibility("default")))。
解决方案不是写两套宏，而是用 CMake 自动生成头文件控制宏：
configure_file(
"${CMAKE_SOURCE_DIR}/include/mylib_export.h.in"
"${CMAKE_BINARY_DIR}/include/mylib_export.h"
)
其中 mylib_export.h.in 写：
#if defined(_WIN32) || defined(__CYGWIN__)
#ifdef MYLIB_BUILDING_DLL
#define MYLIB_API __declspec(dllexport)
#else
#define MYLIB_API __declspec(dllimport)
#endif
#else
#ifdef __GNUC__
#define MYLIB_API __attribute__((visibility("default")))
#else
#define MYLIB_API
#endif
#endif
- 必须在
add_library()后加set_target_properties(mylib PROPERTIES POSITION_INDEPENDENT_CODE ON)，否则 macOS 的 DYLIB 会 link 失败 - Linux 下若用
add_library(mylib SHARED ...)，默认生成libmylib.so；Windows 下生成mylib.dll，但 import lib 是mylib.lib，名字不统一，建议用set_target_properties(... PROPERTIES OUTPUT_NAME "mylib")统一基础名 - macOS 的 rpath 必须设：
set(CMAKE_MACOSX_RPATH ON)，否则运行时找不到依赖 dylib
if(APPLE) 没覆盖到 ARM64 架构、或是 Toolchain 里 sysroot 路径少了个 trailing slash。每次切换平台前，先确认 cmake -E capabilities 输出是否匹配预期，比盲目改 CMakeLists 更省时间。 
