ideavim 是 clion 中 c/c++（尤其嵌入式）开发的底层依赖，必须启用并配置 ~/.ideavimrc（如 set timeoutlen=500、禁用原生 vim 模拟），配合 rainbow brackets lite（扩至6–8色）和 stm32cubecli 1.8.0+ 才能高效处理宏展开、头文件跳转与烧录集成。
IdeaVim 插件必须开，否则你在 CLion 里写 C/C++ 就像开车不踩油门。它不是“可选增强”，而是重构整个编辑节奏的底层依赖——特别是嵌入式开发中频繁切换寄存器宏定义、头文件跳转、快速注释/取消注释时，ci{、vi"、zf 这类操作比鼠标点十次还快。
- 不要只装插件，要配
~/.ideavimrc：比如加set timeoutlen=500防止2i被误判成两次i；加nnoremap <c-j> :tabnext<cr></cr></c-j>统一标签页切换逻辑 - 禁用 CLion 原生的 “ Vim 模拟”（Settings → Editor → Vim Emulation），只留
IdeaVim插件生效，否则快捷键冲突会导致光标突然失焦或粘滞 - 如果你用 STM32CubeMX 生成代码，
ci{配合 Rainbow Brackets Lite 能秒级定位MX_GPIO_Init()内部嵌套的HAL_GPIO_WritePin()调用链
Rainbow Brackets Lite 是嵌入式项目里最被低估的视觉辅助工具。它不改逻辑、不加功能，但能让你在 3 层以上宏展开 + 条件编译 + 模板特化混杂的代码里，一眼识别出哪对括号属于 #ifdef STM32H7xx 分支，哪对属于 std::array<uint8_t></uint8_t> 初始化。
- 默认颜色数只有 4 种，遇到
std::tuple<int float char std::vector>, std::function<void>></void></int>这种类型，括号会复用颜色 → 在插件设置里把rainbowbrackets.colors扩展到 6–8 种 - 它和 CLion 2026.2 新增的
C++26 反射高亮共存时，括号颜色优先级高于反射属性标记（如[[reflect]]），这点不影响阅读，但调试时别误以为颜色变化是反射语法错误 - 关闭 “Highlight current scope” 选项，否则在长函数里光标所在行括号会被加粗+变色，反而干扰对齐判断
STM32CubeCLT 或 STM32CubeCLI 插件不是“提高效率”，而是决定你能不能把 CubeMX 工程真正接入 CLion 构建流。2026.2 版本起，CLion 不再推荐手动拖 .ioc 文件进项目，而是通过 CLI 自动拉取对应芯片的 HAL 库、CMSIS、ST-LINK GDB Server —— 你改了 main.c，make flash 命令就能直接烧录，不用切回 CubeMX 点生成。
- CLI 必须用 1.8.0+ 版本，旧版不识别 CLion 2026.2 的
Debug Profiles格式，会导致 ST-LINK 连接失败且报错Failed to start ST-Link GDB server: unknown option '--multi' - 在 Settings → Build, Execution, Deployment → Console → STM32CubeCLI 中指定完整路径，例如
D:\tools\stm32cubecli\bin\STM32CubeCLT.exe，不能只填目录 - 如果你用 Zephyr，别装这个插件——Zephyr West 已内置等效 CLI，强行启用会和
west build冲突
Fitten Code 在 C++ 场景下容易翻车，不是它不好，而是补全边界太模糊。比如你输入 for auto x :，它可能补全成 range-based for，也可能补成 for_each + lambda，取决于当前文件是否包含 <algorithm></algorithm> 头文件——而 CLion 的头文件分析在大型嵌入式项目中常有延迟。
- 必须关闭 “Use local model”，该选项在 2026.2 插件版本中仍无实际支持，开启后所有 AI 补全静默失效，且 IDE 不报任何提示
- 把补全延迟从默认 300ms 改为
150ms（Settings → Editor → General → Code Completion → Autopopup delay），否则在写中断服务函数时，HAL_UART_RxCpltCallback这种长名还没输完，补全框就消失了 - 它的
Ctrl+Alt+E（Edit Code）对 HAL 库调用重写很危险：把HAL_Delay(10)改成osDelay(10)时不会检查 FreeRTOS 是否已启用，得靠你人工核对cmsis_os.h是否包含
真正卡住效率的从来不是缺插件，而是插件之间互相覆盖行为。比如 IdeaVim 和 Fitten Code 共用 Ctrl+Alt+C 时，按下去到底是打开聊天窗口还是进入 Vim 的命令模式，取决于哪个插件加载得更晚——这种冲突不会报错，只会让你某天突然发现 :q 退出不了编辑器。
