GCC命令行怎么开启编译优化

-O2通常是最常用、也相对最稳妥的一档优化选项。原因不复杂：它在编译耗时、调试友好度和程序运行性能之间，拿捏得比较均衡；像函数内联、循环优化这类常见优化都会开启，整体兼容性也不错，同时还能配合-g进行调试。相比之下，-O3的优化力度虽然更激进，但带来的副作用也往往更明显，所以使用时最好多留一分谨慎。

直接用 -O 系列参数就行，不用改代码或配环境

GCC 默认采用的是 -O0，也就是零优化状态，编译时基本不会主动做额外优化。要把优化打开，其实很简单，在命令行里加上一个以 -O 开头的选项就行，比如 -O1、-O2 或 -O3。不过要注意，这几个选项并不是单纯的“开或关”，而是代表了不同强度的一整套优化策略集合——每个级别都会自动带上一组对应的优化标志，并不是在前一个基础上做简单叠加。

-O2 是最常用也最稳妥的选择

多数项目（包括嵌入式 GUI、服务端工具、命令行程序）用 -O2 就够了。它在编译时间、调试友好性和运行性能之间取得了实际可用的平衡。

• -O2 会启用函数内联、公共子表达式消除、循环优化、指令调度等，对 CPU 占用和执行速度有明显改善（比如 LVGL 移植中 CPU 使用率从 99% 降到 50%）
• 它不会像 -O3 那样激进展开循环或做可能破坏调试变量映射的变换
• 调试时仍能较可靠地单步、查看局部变量（-g 和 -O2 可共存）
• 不改变浮点运算语义，也不依赖特定 CPU 指令集，兼容性好

-O3 不是“更高就是更好”，得看场景

它比 -O2 多启用向量化、更激进的内联、循环展开等，但副作用也更明显：

• 编译时间显著增加，内存占用翻倍常见
• 某些变量可能被完全优化掉，GDB 调试时显示
• 对浮点精度敏感的代码（比如科学计算、金融逻辑）可能因重排或融合运算而结果偏移
• 生成的二进制更大，对 flash 受限的嵌入式设备要小心
• 如果源码里用了 volatile 或信号处理，-O3 有时会绕过预期行为

别漏掉 -Wall 和 -g 这两个搭档

优化本身不帮你发现逻辑错误，但配合警告和调试信息，才能真正稳住质量：

• -Wall 必须加 —— 它暴露未初始化变量、无返回值函数、隐式类型转换等问题，这些在优化后更容易引发诡异行为
• -g 和 -O2 一起用没问题，调试体验虽不如 -O0，但远好于 -O3；发布版可去掉 -g 减小体积
• 如果想保留调试能力又压体积，试试 -Og：它是专为调试设计的优化级别，比 -O0 快，又比 -O2 更易调试

实际编译命令示例：

gcc -O2 -Wall -g -o app main.c

gcc -O3 -march=native -DNDEBUG -o app main.c

真正容易被忽略的是：优化效果高度依赖代码结构。比如一个空循环、重复调用未声明 inline 的小函数、或者大量全局变量访问，再高的 -O 级别也救不了。先让代码干净，再让编译器发力。