extract function 应用于重复、内聚且职责无关的代码块，如 hal 初始化组合；clion 自动推导输入变量但不处理返回值检查、static 变量或 goto，需手动干预。
CLion 的代码重构不是“点几下就变好”的魔法，而是需要理解意图、选对时机、避开陷阱的实操过程。用错场景或忽略上下文，反而会让代码更难维护。
什么时候该用 Extract Function 而不是手写函数
当你看到一段重复出现、逻辑内聚但和当前函数职责无关的代码块时，Extract Function 才真正值得触发。比如 HAL 初始化中反复写的 __HAL_RCC_GPIOA_CLK_ENABLE() + GPIO_Init() 组合。
- CLion 会自动推导输入变量（如
GPIO_TypeDef*,GPIO_InitTypeDef*），但不会猜你是否想把HAL_GPIO_Init的返回值检查也包进去——这得手动补 - 如果选中的代码里有局部
static变量或goto标签，Extract Function会直接禁用，别硬试 - 生成的函数默认放在当前文件末尾；若想塞进头文件，得在对话框里勾选
Declare in header并确认头文件已#include
Change Signature 别乱动 const 和引用参数
对 void process_data(const std::vector<int>& v)</int> 执行 Change Signature 时，加个新参数容易，但改 const 或引用类型会引发连锁编译失败。
- 添加参数：安全，CLion 会自动在所有调用处补默认值（如
int flag = 0） - 移除参数：危险，除非确认所有调用都传了相同字面量（比如全是
process_data(v, 1)），否则必须手动修复调用点 - 把
const std::string&改成std::string：可能触发隐式拷贝，性能敏感路径要盯紧反汇编或 profiler 数据
Inline 不等于“删掉”，它可能暴露隐藏依赖
Inline 看似是“把函数展开”，实际是让 CLion 把函数体原样插进每个调用点，并删掉原函数声明。但它不会帮你处理宏、模板特化或 SFINAE 分支。
- 对带
static局部变量的函数Inline，会导致每个调用点都有一份独立副本——行为彻底改变 - 若函数被多个翻译单元调用（比如定义在 .cpp 里但声明在 .h 中），
Inline后其他文件会链接失败，报undefined reference - 调试时发现某函数内联后断点失效？检查是否误点了
Inline而非Extract Function
重命名符号前先关掉 “Search in comments”
对 UART_HandleTypeDef 这类 HAL 库类型重命名，勾选 Search in comments 很可能把 CubeMX 生成的注释（如 // UART1 init function）也改掉，后续重新生成工程时冲突。
- 只在项目私有代码中重命名：取消勾选，作用域限定为
Project - 改完立刻检查
CMakeLists.txt和compile_commands.json是否还引用旧名——CLion 不管构建系统层面的字符串 - 如果重命名后出现
no member named 'Instance'类错误，大概率是 HAL 库头文件里的宏定义没跟着变，这类不能靠 IDE 自动处理
最常被忽略的一点：CLion 的重构预览（Preview）窗口里，红色高亮的“潜在风险行”不是建议，是明确警告——比如跨线程访问的变量被提取后未加锁，它不会提醒，但会照常执行。
