大概三年前我在团队里推行 CLion 的时候遇到阻力其实不小。用过 Visual Studio 和 Eclipse 的老同事问得最多的就是“这玩意儿到底比 VS 强在哪”说实话当时我也答不出太多。真正把 CLion 用顺之后我才慢慢明白它和传统 C/C IDE 有一个很根本的区别CLion 不是去“读取”你的工程而是尝试“理解”你的工程。这话听起来有点玄但理解了这一层后面所有技巧基本都能串起来。这篇文章主要讲我这两年真正用得上、也确实帮我省下不少时间的东西覆盖环境配置、日常编辑、调试、嵌入式开发和几个高频问题场景。如果你正准备从 Visual Studio 或者 Keil 迁过来或者已经用 CLion 但总觉得效率上不去这篇应该能给你一些可以直接抄作业的内容。内容基于我个人项目的实际操作经验参数和步骤都按常见实践来写不会有那种“配置完反而更懵”的事。1. 环境配置与工程模型CLion 的地基1.1 第一次启动3 个配置决定了未来几年的使用体验很多人装完 CLion 第一件事是写 Hello World其实在此之前有几个配置花两分钟弄好后面会舒服很多。先说安装本身我强烈建议用 JetBrains Toolbox 而不是单独下安装包。Toolbox 的好处不只是方便升级更重要的是它能多版本共存今天用 2024.1明天想试 2024.2随时切遇到新版本 IDE 插件不兼容也有后悔药吃。第一次启动后建议先改三处。第一处是键位方案。CLion 默认是 IntelliJ IDEA 的键位用惯 VS 的人会觉得 AltEnter 之类很别扭。在 Settings - Keymap 里直接选 Visual Studio 预设大部分习惯能无缝迁移从 Eclipse 转过来的就选 Eclipse 预设。很多人不知道这个设置硬啃默认快捷键其实没必要工具是为人服务的。第二处是编码。在 Settings - Editor - File Encodings 里把 IDE Encoding 和 Project Encoding 都设成 UTF-8底下的 Default encoding for properties files 也改成 UTF-8。这一步能避免掉后面一半的乱码问题尤其是 Windows 上做跨平台项目的时候。第三处是滚轮缩放。Settings - Editor - General 里勾上 Change font size with CtrlMouse Wheel演示代码或者接投影仪时不用临时去改字号非常实用。这三个配置加在一起一分钟就搞定但影响的是你未来几年天天面对的工具手感值得一开始就弄好。1.2 Toolchain 选型MinGW、MSVC、WSL 到底怎么选很多人第一次用 CLion 会懵因为 CLion 不自带编译器也不自带调试器。它更像一个“壳”把 CMake、GCC/Clang/MSVC、GDB/LLDB 这些底层工具串起来给你一个可视化界面。所以 Toolchain 配置是第一个绕不过去的坎。在 Windows 上主流有三种 Toolchain。我用一张表来对比方便你根据自己场景选Toolchain适用场景调试器配置难度MinGW-w64本地 Windows 小程序、跨平台项目GDB低用 MSYS2 装最省事MSVC需要调 Windows API、对接 Visual Studio 生态CDBCLion 集成中需要装 VS Build ToolsWSLLinux 开发为主目标部署在服务器/嵌入式GDB远程/本地中依赖 WSL 环境个人建议是如果你做的东西最终要在 Linux 上跑直接用 WSL Toolchain如果只是 Windows 本地工具MinGW 就够。MinGW 的安装我不建议去网上随便下个压缩包正路是用 MSYS2。装好 MSYS2 后在它的终端里执行pacman -S mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb mingw-w64-ucrt-x86_64-cmake mingw-w64-ucrt-x86_64-ninja装完后把 C:\msys64\ucrt64\bin 加进系统 PATH回到 CLion 的 Settings - Build, Execution, Deployment - Toolchains它一般会自动检测到 gcc/g/gdb。检测不到就手动点文件夹图标记一下路径。这里有个小坑装了 32 位和 64 位混用的话CLion 可能识别到多个编译器你最好在 Toolchain 里固定选 64 位那套不然编译和调试器版本不一致调试时经常出现“看不到局部变量”这种诡异问题。1.3 工程模型CMake 是 CLion 的灵魂CLion 对 CMake 的支持是目前所有 IDE 里做得最深的但这也意味着如果你不懂 CMakeCLion 的很多高级功能你都用不上。反过来说一旦你理解了 CMakeCLion 的索引、补全、跳转都会变得极度精准。最基础的 CMakeLists.txt 长这样cmake_minimum_required(VERSION 3.20) project(my_app C CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(my_app main.cpp utils.cpp)CLion 会读取这个文件自动生成 compile_commands.json等价结构内部使用然后基于它做代码分析。这就是为什么别人给你一个没有 CMakeLists.txt 的源码目录CLion 会提示“No CMakeLists.txt found”——它没法理解你的工程结构。这时候最常见的做法是自己新建一个根 CMakeLists.txt把源文件通过 glob 或者逐个 add_executable 加进去CLion 立刻就能识别。还有两个概念必须搞清楚Profile 和 Build Directory。CLion 右下角有个 CMake Profile 切换按钮默认有 Debug 和 Release。Debug 开 -g 不带优化Release 开 -O2 不带调试信息。很多人遇到“为什么 Release 下断点断不下来”的疑问80% 是 Profile 没切对。Build Directory 则是构建产物目录如果你在 CMakeLists 里硬编码了绝对路径可能影响 CLion 自动生成的 build 目录建议让它保持默认。2. 日常开发效率把 IDE 用到日常手感2.1 导航与搜索跳转要快搜索要准CLion 的日常效率核心就在导航。刚开始可能不习惯但用熟之后鼠标的使用频率会大幅降低。最常用的三个动作Ctrl点击跳转到定义AltF7 查找所有引用双击 Shift 弹出 Search Everywhere。Search Everywhere 是很多人没有意识到的“瑞士军刀”。它能搜文件名、类名、函数名还能搜 Action也就是说你忘了某个设置项在哪直接双击 Shift 输入设置名就能跳转。比如想找“File Encoding”敲进去回车就到了不用一层层点菜单。再看几个容易被忽略的CtrlF12 打开当前文件的符号列表适合看一个几千行的类里有哪些成员函数CtrlShiftF 是全文搜索带正则支持F11 添加书签CtrlF11 可以加带数字/字母的书签按 Ctrl数字直接跳过去。我经常在一个大项目里给关键函数打书签比反复用搜索高效得多。很多人不知道 CLion 支持多重剪贴板CtrlShiftV 可以弹出历史复制记录。当你连续复制了好几段代码、最后发现需要早先复制的那段时这个功能能救命。2.2 重构与实时模板让 CLion 替你改代码C/C 的重构在 VS 里其实比较弱但 CLion 做得非常扎实。我日常用得最勤的是 ShiftF6 重命名。它不是简单的字符串替换而是基于符号语义的重构重命名一个类名所有相关的构造、析构、文件名建议都会一起处理重命名一个局部变量只影响当前作用域不会误伤同名变量。抽取也是高频操作。选中一段代码按 CtrlAltM 可以抽取成一个函数CtrlAltV 抽取变量CtrlAltC 抽取常量。这种重构对清理历史遗留代码特别有用。我接手过一个 2000 多行的函数就是靠不断抽取把大函数拆成十来个逻辑块最后可读性完全不一样。CLion 的重构菜单里还有“Change Signature”和“Extract Interface/Class”前者适合大规模改接口参数后者适合做面向对象设计调整。实时模板是另一个被低估的功能。Settings - Editor - Live Templates 里可以自定义比如我常写头文件保护宏#ifndef ${NAME}_H #define ${NAME}_H #endif // ${NAME}_H定义一个缩写叫 vh之后在代码里输入 vh 再按 Tab直接展开。配合变量表达式CLion 还能自动填充文件名为宏名。这个能力在写新模块时特别香能省掉大量重复劳动。2.3 运行配置代码之外的“运行参数”管理很多初学者点右上角的绿色三角直接 Run跑起来是没问题但一旦需要传命令行参数、设置工作目录、配环境变量就不知道怎么操作了。其实这些都在 Edit Configurations 里。打开 Run/Debug Configurations 窗口每个 CMake target 都会自动生成一个默认配置。你可以点左上角的加号针对同一个 target 创建多个配置比如一个带 -v 详细日志一个不带一个用 test.conf一个用 prod.conf。Work Directory 设置也很关键如果你的程序要读相对路径下的配置文件工作目录不对就会莫名其妙找不到文件。这里分享一个经验如果你同时调试服务端和客户端或者同时跑多个程序记得把配置里的 Allow parallel run 勾上。否则 CLion 每次会提醒你“已经有进程在运行”打断调试节奏。同一份代码不同配置对应不同启动参数这是平时最实用的技巧之一。3. 调试实践从同一项目多目标到嵌入式板子3.1 同一项目多目标调试一个工程里跑多个程序“CLion 调试同一项目多个目标程序”是我被问过很多次的问题。典型场景是一个 CMake 工程里既有服务端又有客户端或者有几个独立的小工具你希望分别启动它们然后在各自的进程里打断点、看变量。先看 CMake 侧怎么做add_executable(server server.cpp common.cpp) add_executable(client client.cpp common.cpp)这样定义之后CLion 会在 Run/Debug Configurations 里自动生成两个 target。接下来我在配置列表里分别选中 server 和 client把 Allow parallel run 都勾上。启动时先 Debug server再回到配置列表选 Debug clientCLion 会保持第一个调试会话同时开启第二个。在 Debug 工具窗口的会话下拉框左上角里可以在多个调试进程之间切换每个进程有独立的断点、变量表和调用栈。如果你需要调试的是同一个程序的多开场景比如多个 worker 进程那就在同一个 target 上新建多个配置每个配置传不同参数同样勾选并行运行。CLion 的调试器是多会话隔离的断点默认只作用于当前会话不会互相干扰。在服务端/客户端联调的时候两个进程都能下断点找线上问题比之前只用 printf 肉眼比对日志高效太多。3.2 条件断点、数据断点与异常断点调试不是只有 F8 和 F9。右键一个断点你会看到一堆选项。条件断点是最常用的。在断点右键弹窗里写 i 100只有当变量 i 等于 100 时才中断。写进循环里分析特定数据、或者排查第 N 次调用出错时这个东西省时省力。条件里还能用函数调用比如 strlen(name) 10不过注意 GDB 环境下条件表达式性能会受影响循环体特别大时要谨慎。日志断点我称它是“不需要打断点的 printf”。在断点设置里勾上 Log evaluated expression输入某个变量运行时不中断但每次命中都会往 Console 输出一行。这样不用改代码加日志也不用反复编译。逻辑复杂、又不想污染源码的场景日志断点和条件断点组合使用效果比传统调试好很多。数据断点的英文叫 Data Breakpoint在很多调试器里也叫 Watchpoint。它的作用是监控某个内存地址或者变量当值被修改时触发中断。排查“谁动了我的全局变量”这种问题数据断点是唯一的正解。在 Variables 面板里右键变量选择 Add to Watch / BreakpointCLion 会记录当前地址并在写入时停下来调用栈直接告诉你凶手是谁。异常断点在 CLion 的 Breakpoints 对话框里可以针对 C exception 添加断点。这个在排查崩溃问题特别有用。比如一段代码抛了 std::bad_alloc 或者别的什么普通断点很难定位到抛掷点异常断点直接把程序停在异常抛出的地方你自己再顺着调用栈找 root cause 就行。3.3 嵌入式调试CLion STM32 OpenOCDCLion 做嵌入式开发已经不只是“能用”的程度。如果你用 STM32CubeMX 生成工程CubeMX 从 1.6 版本开始可以直接把工程生成成 CMake 格式。在 CubeMX 的 Project Manager - Project - Toolchain 下拉里选 CMake然后生成。这样出来的目录里有完整的 CMakeLists.txtClion 直接打开文件夹即可。接着配置工具链。在 Settings - Toolchains 里新增一个使用 arm-none-eabi-gcc 编译器路径指向你安装 ARM 工具链的 bin 目录。这个工具链在很多发行版里可以直接装Ubuntu 下 apt install gcc-arm-none-eabiWindows 下用 xPack 或者 ARM 官方包。调试配置选 OpenOCD。下载并安装 OpenOCD 后Debug Configuration 里选择 Embedded GDB Server再选 OpenOCD设置 configuration file 路径。以 STM32F103 为例配置文件一般指向interface/stlink.cfg target/stm32f1x.cfg连接 ST-Link 和开发板后点 DebugOpenOCD 会通过 GDB 和 arm-none-eabi-gdb 配合CLion 里可以直接下断点、看外设寄存器。串口日志可以一边调试一边在串口助手里看。CLion 对嵌入式调试最大的优势是图形化地显示寄存器和外设状态不用像命令行 GDB 那样敲命令。我自己做 STM32 项目时还发现一个小技巧把 OpenOCD 的启动命令直接写在 CMake 的 custom target 里这样不需要额外开终端烧录CLion 的 Run 面板里就能一键下载程序add_custom_target(flash COMMAND openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c program build/my_app.elf verify reset exit DEPENDS my_app )4. 高频问题排查乱码、SLN 与 JNI4.1 中文输出乱码的根治方案CLion 在 Windows 上的中文乱码基本是两个根源一是源码文件编码和编译器/终端不一致二是 Windows 控制台的代码页问题。先说源码文件。如果你打开一个来自 Windows 老项目的 .c/.cpp 文件发现中文注释全是乱码那大概率文件本身是 GBK/GB2312 编码。这时候不要急着全局改编码先右键文件 - File Properties - File Encoding把单个文件临时切成 GBK 预览确认能正常显示后再用 Convert Encoding 转成 UTF-8。如果你希望以后默认都用 UTF-8就回到 1.1 节提到的 File Encodings 三处设置统一改。再说到运行时的中文输出。程序编译出来在 CLion 的 Run 窗口里显示 ??????或者更常见的“烫烫烫”这类乱码多半是因为 Windows 控制台默认代码页是 936GBK而你的源码和程序按 UTF-8 输出。几个修复手段可以组合使用Windows 10/11 设置 - 时间和语言 - 语言和区域 - 管理语言设置 - 更改系统区域设置勾选“Beta: 使用 Unicode UTF-8 提供全球语言支持”重启。这个方案最彻底缺点是某些老软件会受影响。在 CLion 的 Run/Debug Configuration 里把 Console 设置里的 Default encoding 改成 UTF-8。在 CMakeLists.txt 里给编译器加参数比如 GCC 的-finput-charsetUTF-8 -fexec-charsetUTF-8这样即使源码是 GBK 也能编出 UTF-8 可执行文件但注意这只保证程序内部字符串正确终端还是得有 UTF-8 能力。不想改动全局也可以把普通项目里加一行add_compile_options(-finput-charsetUTF-8 -fexec-charsetUTF-8)我个人的最终方案是所有源码统一 UTF-8系统开启 UTF-8 BetaCLion 编码设置三处全 UTF-8。这样再也不出现中文相关的幺蛾子。4.2 直接打开 .sln 工程要注意什么如果你拿到一个 Visual Studio 的 .sln 工程又不想那么快折腾迁移CLion 从 2023.1 开始支持直接打开 .sln 文件。它内部会把 MSBuild 的结构通过 CMake 桥接转换成 CLion 能识别的工程模型然后在你的磁盘上生成一个 CMakeLists.txt 附带文件。直接在 File - Open 选中 .sln 文件后CLion 会先问你 Toolchain。此时 Windows 上建议选 MSVC 工具链因为很多 .vcxproj 里依赖了 MSVC 特有的编译选项用 MinGW 可能编译不过。项目打开后不一定 100% 等价于 VS 里的构建行为特别是那些涉及自定义 MSBuild Target、Pre/Post Build Step、或者用了 vcpkg 集成的复杂工程在 CLion 里可能报“unknown compiler option”或者库找不到。所以如果你的目标只是临时看看代码、做点跨平台小改动用 CLion 打开 .sln 没问题但如果要长期维护我还是推荐把工程迁移成 CMake。迁移成本没有想象中那么高核心就是列出源文件、加 include 目录、加链接库。遇到第三方库就用 find_package 或者直接写路径。迁移完你会发现 CMake 在 Linux、Windows、macOS 上都能用团队协作也方便。4.3 在 CLion 中搭建 JNI 环境JNI 场景我是在做一个音频处理工具时遇到算法部分用 C 写UI 用 Java 调。CLion 配置 JNI 其实不难核心是两步让编译器找到 JNI 头文件然后把你实现的动态库输出到 Java 能加载的位置。JNI 的头文件路径取决于你的 JDK 安装。典型的路径是${JAVA_HOME}/include/jni.h ${JAVA_HOME}/include/linux/jni_md.h // Linux ${JAVA_HOME}/include/win32/jni_md.h // Windows在 CMakeLists.txt 里用一个变量指到 JDK 根目录然后set(JAVA_HOME C:/Program Files/Java/jdk-17) include_directories( ${JAVA_HOME}/include ${JAVA_HOME}/include/win32 ) add_library(native_audio SHARED native_audio.c)Java 侧的流程是写一个声明了 native 方法的类然后用 javac 的 -h 参数生成头文件javac -h . com/example/AudioProcessor.java它会生成一个 com_example_AudioProcessor.h里面声明了对应的 JNIEXPORT 函数。把这个函数实现填好编译出 native_audio.dllWindows或 libnative_audio.soLinux最后在 Java 代码里System.loadLibrary(native_audio);JNI 调试在 CLion 里也能做Java 侧跑起来后CLion 里用 Attach to Process 附加到 Java 进程然后在 C 代码里下断点IDE 一样能停下来看局部变量。这一套配好后JNI 开发的效率比用 javac 编译、再用 System.out.println 排查高很多。5. 插件市场与工程扩展5.1 插件商店搜不到 Continue手动安装最近总有朋友问在 CLion 的插件商店里搜不到 Continue 插件。这不一定是你网络的问题更多时候是插件市场在不同地区、不同 IDE 版本下的可见性不一致或者插件自身还没适配你的 CLion 版本。遇到这种情况最靠谱的办法是手动安装。到 Continue 的 GitHub Releases 页面下载对应 CLion 版本的插件 zip 包然后在 CLion 的设置里打开 Plugins点右上角的齿轮图标选择 Install Plugin from Disk选中 zip 文件重启 IDE 即可。手动安装的插件会在已安装列表里出现后续也可以像普通插件一样卸载。这个思路其实适用于所有商店搜不到的插件Rainbow Brackets、GitToolBox 这类知名插件一般商店都有但一些小众插件或者测试版商店没有时手动安装是唯一路径。装插件前先看它支持哪些 IDEs 和版本号装上之后如果发现 IDE 卡顿明显考虑禁用而不是死扛。5.2 值得保留的几个插件与取舍插件不是越多越好。我实际体验过装了十几个插件的状态CLion 启动直接慢了半分钟索引也变慢。最后留下的核心组合是Rainbow Brackets括号配对率提高很多特别适合表达式复杂的 C 代码不同层级括号颜色不同眼睛不累了。Native Terminal在 IDE 里直接开系统终端做交互式命令比内置终端顺滑一点尤其 macOS 上习惯 iTerm 的人会喜欢。GitToolBox状态栏显示当前分支、提交时间、文件修改状态对日常 Git 工作流很有帮助。SonarLint可选能提示潜在的代码问题适合质量要求高的项目不过它会在大型代码库上增加 CPU 占用看需求取舍。这里我多提醒一句CLion 内置的 Git、反编译查看器、数据库插件其实已经很能打了先熟悉内置功能再决定装不装插件。否则很容易陷入“装了不用卸载又怕错过”的怪圈。5.3 代码规范与团队协作clang-format / clang-tidy如果你的团队对代码风格有要求CLion 内置的 clang-format 支持是加分项。Settings - Tools - ClangFormat 里可以选在保存时自动格式化配合 .clang-format 配置文件团队所有人统一风格diff 干净很多。对大规模 C/C 项目来说这一条配合 CI 的格式检查能省掉无数代码评审里的“这行缩进不对”问题。clang-tidy 则是比编译器警告更深一层的静态检查。CLion 的 Inspections 里内置了大量 clang-tidy 规则比如某些可能越界访问的模式、未定义行为、异常安全问题等开了之后写代码时会有实时提示。我一般在项目目录放一个 .clang-tidy 文件设定团队相关的检查项避免默认规则太多导致噪音过大。在较老的代码库上启用时建议先跑一遍并看警告密度再决定纠不纠避免一次改动范围爆炸。最后再分享一点个人体会我经常跟人说CLion 最大的学习成本其实不是快捷键而是理解它背后的“构建即索引”思路。CLion 的代码补全和跳转依赖 CMake 生成的信息所以你真正要懂的是 CMake、是 GDB、是你项目本身的构建方式IDE 只是把这些底层工具变成可视化的交互层。这个观念转过来之后CLion 大部分功能几乎不用学就通了。另一个体会是不要追求一次把所有设置都配好。你可以在项目进展中慢慢调整 Toolchain、编码、Format 模板CLion 绝大多数设置都是热生效的。工具是给人用的别让配置本身变成负担。如果你按照上面几节把基础打好再逐步把多目标调试、JNI、嵌入式流程串起来你会发现 CLion 能覆盖的场景比你最初想象的宽得多。如果这篇文章里有哪些地方你实际跑下来和我不一样欢迎按你自己的环境再调毕竟每个人的项目都不一样。
