CLion
C++ 能被索引，不代表它能用当前 ABI 构建
CLion 打开 CMakeLists.txt 后，代码补全很快恢复，开发者便以为项目模型已经正确。真正链接时才发现 IDE 选了另一套编译器，build directory 里还残留上一 profile 的 cache；二进制能启动，断点却由不匹配的 debugger 接管。C++ 工程中的“工具链”不是一个编译器路径，而是构建系统、生成器、编译器、架构、标准库、调试器与运行环境的组合。
CLion 支持 CMake、Makefile、compilation database、Meson 等项目入口。本文以 CMake 为主轴，因为它最能展示共享项目事实、机器 toolchain 与 IDE profile 的边界。其他入口也遵循同一原则：先让命令行工具链在目标环境成立，再让 CLion 导入，不把项目描述藏在个人 .idea 中。
安装前先决定目标平台与许可
个人开发机通常用 JetBrains Toolbox 安装稳定版 CLion，并保留上一实例进行升级回退。组织软件分发可以使用官方 standalone 包；Windows 还要独立准备 MSVC Build Tools、MinGW/Cygwin/WSL 或批准的交叉工具链，macOS 需要匹配的 Xcode Command Line Tools，Linux 则需编译器、CMake、构建工具与调试器。
安装完成，从 Help | About 记录 CLion build、IDE runtime、OS/CPU，再确认商业许可、代理、企业 CA 与批准插件。个人非商业许可与公司业务席位必须区分。工具链的编译器、SDK、sysroot 和第三方库也有自己的许可证，CLion 订阅不替它们授权。
升级 IDE 时固定 CMake、compiler、generator 与 debugger，用代表项目完成 configure、build、test、run、debug、stop。之后再单独升级工具链。C++ ABI 与调试信息很敏感，把 CLion、编译器和依赖一次全升，失败后很难定位。旧 IDE 实例、旧工具链和独立 build directory 是三种不同回退入口。
项目事实、toolchain 与 profile 不在同一层
仓库中的 CMakeLists.txt、CMakePresets.json 与 toolchain file 描述可共享的项目与构建意图。CLion Toolchains组合 CMake、build tool、C/C++ compiler 和工作环境；在新版本中 debugger 逐步由独立 debug profile 选择，不能长期假设它只是 toolchain 里的固定字段。
CMake Profile再选 toolchain、build type、generator、CMake options、environment 与 build directory。CMakePresets.json 适合提交项目级配置，CMakeUserPresets.json 适合本机配置且不应提交。CLion 能把 Preset 导入 Profile，但 Profile 仍会引用 IDE 本机的 toolchain/debugger 等信息；二者不是重复文件。
先在外部终端保存工具链指纹：
cmake --version
cmake --list-presets
cmake --preset dev
cmake --build --preset dev
ctest --preset dev --output-on-failure仓库没有 Preset 时，显式创建独立目录：
cmake -S . -B build\dev -G Ninja -DCMAKE_BUILD_TYPE=Debug
cmake --build build\dev
ctest --test-dir build\dev --output-on-failure输出需要说明 generator、C/C++ compiler、目标架构和 build directory。CLion Profile 应消费相同 preset 或等价参数。若 IDE 只显示一个名为 Default 的 toolchain，仍要打开 CMake 输出确认实际路径。
用两套编译器证明 build directory 不能混用
下面的实验使用系统可用的两个 C++ 编译器时最有价值；如果机器只有一个编译器，也可以先阅读输出链，改由 CI/代表性开发机执行。示例先生成一个记录 compiler ID 的文件，再尝试用另一编译器复用同一 build directory。
$lab = Join-Path $env:TEMP "clion-toolchain-lab"
Remove-Item -Recurse -Force $lab -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path $lab | Out-Null
@'
cmake_minimum_required(VERSION 3.20)
project(toolchain_lab LANGUAGES CXX)
file(WRITE "${CMAKE_BINARY_DIR}/compiler.txt" "${CMAKE_CXX_COMPILER_ID}|${CMAKE_CXX_COMPILER}")
add_executable(toolchain_lab main.cpp)
'@ | Set-Content -Encoding utf8 (Join-Path $lab "CMakeLists.txt")
@'
#include <iostream>
int main() { std::cout << "toolchain-ok\n"; }
'@ | Set-Content -Encoding utf8 (Join-Path $lab "main.cpp")
cmake -S $lab -B (Join-Path $lab "build-a") -G Ninja
cmake --build (Join-Path $lab "build-a")
Get-Content (Join-Path $lab "build-a\compiler.txt")
cmake -S $lab -B (Join-Path $lab "build-a") -D CMAKE_CXX_COMPILER=clang++
$switchExit = $LASTEXITCODE
"switch_exit=$switchExit"
Remove-Item -Recurse -Force $lab如果首次已是 Clang，第二次把 clang++ 换成另一可用编译器。CMake 可能拒绝切换、要求重新配置，也可能留下提示并重建部分状态；无论具体表现，证据都应促使团队为不同 compiler/architecture 使用不同 build directory。复用旧 cache 后“configure 成功”不能证明所有对象已用新 ABI 重建。
在 CLion 中为 MSVC、Clang 或 WSL 建独立 toolchain/profile，并使用不同目录。切换 profile 后查看 CMake cache 的 CMAKE_CXX_COMPILER、生成器和架构，再构建运行。删除的是对应派生 build 目录，不是 CMakeLists.txt、Preset 或 toolchain file。
Preset 用于共享意图，Profile 衔接本机工具
CMakePresets.json 可以共享 configure/build/test preset、cacheVariables 与条件。真实个人路径、密钥、临时 sysroot 放入未提交的 CMakeUserPresets.json 或受控环境，不污染项目文件。团队 preset 应在命令行可执行，不能只被 CLion 的 vendor 字段理解。
CLion Profile 可以为同一 preset 选择本机 toolchain、启用/禁用以及调试配置。共享 .idea/cmake.xml 前要检查本地绝对路径和同名 profile 覆盖；官方文档说明同名本地 profile 可能优先于共享 profile，这会造成“所有人看到同名 Debug，实际参数不同”。更稳的是用清晰命名并把关键配置放回 Preset。
环境变量分 parent environment、toolchain environment script 与 profile environment。编译环境脚本可能很慢、修改 PATH/INCLUDE/LIB，并在 CLion 中被缓存。终端成功、IDE compiler 探测失败时，比较环境脚本是否实际加载、shell 与架构是否一致。不要把整个个人环境 dump 进工单，其中可能含凭证。
编译、测试与运行配置必须指向同一产物
CLion 默认在 run/debug 前构建目标，但开发者可以关闭 before-launch build，或 run configuration 指向另一个 profile 的二进制。最小验证应从 CMake/CTest 命令开始，再在 IDE 选择同一 target 与 profile运行。打印程序版本、compiler 信息或构建标识，有助于确认运行的不是旧输出。
CTest 只会运行被 enable_testing() 和 add_test() 注册的测试。IDE 测试窗口显示通过时，仍要比较 ctest --preset 的集合与退出码。某些集成测试需要环境、数据和服务，入口写进 preset/脚本，不依赖个人 Run Configuration。
调试会话要确认 debugger profile、目标架构、符号、源码路径与 PID。GDB、LLDB、MSVC/LLDB 和 DAP backend 能力不同；当前 CLion 帮助已把 debugger 选择从 toolchain 中逐步拆出，旧文章里“toolchain 固定 debugger”的说法不能视为永久事实。断点空心先查看模块和符号，确认 Debug/RelWithDebInfo、优化和 strip 状态，再检查路径映射。
CMake script debugger 只调试 configure 阶段，不调试业务二进制构建。configure 逻辑失败可以用它定位变量与分支；编译/链接失败仍查看 build 命令与日志，运行时崩溃则进入目标 debugger。把三个“调试”入口混为一谈会收集错证据。
交叉编译、容器和远端改变整个执行环境
WSL、Docker、Remote Host 或交叉 toolchain 不只是换 compiler 路径。CMake、编译器、sysroot、头文件、库、调试器和目标进程可能全部在远端，代码可能挂载或同步。团队要画出本地 UI、项目源码、build directory、调试协议和凭证所在位置。
Toolchain file 描述 CMake 如何面向目标平台，不能存真实 SSH 密钥或 registry token。Docker socket、privileged 与挂载权限单独审查；远程主机的生产防火墙、账号和接管流程归部署运维，开发 IDE 只使用受控环境和短期身份。
交叉编译“链接成功”还不能证明目标可运行。需要在目标或可信模拟器上执行最小程序和测试，验证架构、动态库、ABI 与运行时资源。CLion 本地代码分析若使用 host headers，而构建使用 sysroot，会出现导航和编译结论分裂，应回到 toolchain/profile 修正包含路径来源。
插件、代码生成和格式化都属于执行面
CLion 插件与 IDE 同权限，CMake、Meson、嵌入式、远程或 AI 插件可能读源码、执行程序和联网。Required Plugins 只能提醒，团队准入要记录发布者、来源、版本、兼容、数据处理与回滚。内部插件仓库和离线包也要有撤销与过期策略。
代码生成器、clang-tidy、clang-format 和 save action 不应只藏在个人设置。formatter/检查器版本、配置和执行范围回到仓库任务；自动修复先在干净分支查看 diff，避免编译器升级与格式化一起制造大改动。
Compilation database 是另一种项目事实入口。compile_commands.json 应由真实构建生成，路径/参数可能暴露本机与内部 SDK，分享前脱敏；它可以改进分析，但不替代链接、测试和部署。生成文件过期时先重建数据库，不清 IDE 索引碰运气。
清缓存之前先识别是哪一层状态
CMake cache/build directory、编译器缓存、依赖缓存、CLion project analysis、IDE system 目录与 Local History 不是同一对象。configure 错误先查看 CMake 输出和 cache variables；切换 compiler/generator/arch 时新建 build directory。CLI 构建成功、IDE 分析错误时 reload project，输入一致后才重建索引。
编译器缓存和下载依赖可能具有显著离线价值，按 owner、容量和可重建性清理。不要发布删除所有 build* 的递归脚本，它可能命中源码、手工产物或其他工作树。目标必须解析为允许根内的真实路径，并在删除前列出内容与占用进程。
CLion system 目录清理会影响索引、日志和 Local History，卸载 IDE 也不一定删除它。未提交编辑先进入 Git，故障日志脱敏归档，再执行最小清理。离职与退场还要撤销 JetBrains 席位、远程主机、制品源和签名身份。
常见故障围绕 configure、build、link、debug 分型
CMake reload 循环先看 configure 日志、Preset/Profile、环境脚本和缺失依赖；不要先调大 IDE 内存。编译器探测变化要清对应 build directory，保留项目文件。
编译成功、链接失败时比较库架构、ABI、runtime、搜索顺序和 target link interface。IDE 索引正确与链接器选择无关，修复后从干净 build 重新链接。
程序运行、断点不命中时确认构建类型、优化、符号、debugger profile、目标 PID 与源码映射。旧二进制或错误 profile 是高频原因；重新构建正确 target 后再 Attach。
终端成功、CLion 失败时比较 CMake、compiler、generator、环境脚本与 cwd。让 CLion Profile 消费同一 preset/toolchain，不复制一套隐藏 flags。反向情况则查个人 Profile 是否掩盖仓库缺失。
团队支持的是完整工具链组合
CLion 验收应记录 IDE build 与商业许可、项目格式、CMake/构建工具、compiler/架构/标准库、Preset/Profile、测试集合、debugger 与目标环境。代表仓库完成 configure、clean build、test、run、debug、stop，并证明旧版本或旧 toolchain 可回退。
大型 C++ 仓库还要量化 configure、索引、增量/全量构建、内存、build directory 和缓存磁盘。优化先处理项目边界、unity/PCH/module策略、生成物与并行度，再评估远程构建或缓存；关闭分析和缩小目标虽然能提速，也可能降低重构与问题发现能力。
如果项目事实完全是 Visual Studio solution、团队只在 Windows/MSVC 调试，Visual Studio 可能维护成本更低；跨平台 CMake、多 toolchain、嵌入式或远端环境则更能体现 CLion 的价值。退出机制不因选型改变：没有 CLion，仓库仍能通过 CMake/Preset 构建测试；个人 .idea 与 Profile 不持有唯一 flags、路径或秘密。