-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 调试时显示
<optimized out></optimized> - 对浮点精度敏感的代码（比如科学计算、金融逻辑）可能因重排或融合运算而结果偏移
- 生成的二进制更大，对 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 级别也救不了。先让代码干净，再让编译器发力。
