有没有遇到过这两种场景编译出来的固件太大烧录时提示空间不足用调试器单步发现某个变量突然不见了或者循环被优化得对不上源码。十有八九是 GCC 的-O优化等级没选对。一、 -O 优化等级-O大写字母 O不是数字 0是 GCC 用来控制优化强度的开关。它决定了编译器在编译速度 / 执行速度 / 代码体积 / 内存占用之间怎么取舍。等级越高编译器做的事越多生成的机器码通常更小更快但编译更慢调试也更难对应源码。# 小写 -o指定输出文件名注意和 -O 区分gcc myfile.c-omyfile# 大写 -O指定优化等级gcc-O2myfile.c-omyfile术语对照optimization level优化等级、code size代码体积、execution time执行时间、compile time编译时间。二、优化等级GCC 主流优化分为 5 档外加一个Ofast。-O0关闭一切优化默认这是 GCC默认等级。目标只有一个——让编译最快完成同时让调试所见即所得。变量不会被优化掉断点、单步、看变量值都最准代价是代码最大、跑得最慢。很多 IDE新建工程默认就是-O0。提示调试阶段用-O0没问题但正式发布如果还留着-O0固件体积会比较大。-O1最基础的优化在不显著增加编译时间的前提下做最基础的体积和执行速度优化。单独写-O不带数字等价于-O1。适合稍微优化一下但不想等太久的过渡场景。-O2日常发布的推荐在-O1基础上启用更多优化选项用更长的编译时间换取更优的代码。不极端、不冒险稳定性好是绝大多数工程 release 版本的默认选择。发布版先上-O2基本不会错。-O3最高强度优化慎用在-O2的全部优化之上再加更激进的手段比如循环展开loop unrolling、激进的内联等。⚠️重点坑-O3不一定让代码变小反而可能为了提速把代码撑大。而且某些激进优化会让调试信息对不上源码排查问题更痛苦。经验法则除非程序是纯计算密集、且确认-O3收益明显否则别用O3。-Os为体积而生嵌入式首选在-O2的基础上关掉那些会让目标文件变大的优化。专为 Flash/磁盘空间紧张、或 CPU 缓存较小的机器设计嵌入式、单片机、Bootloader 场景的常用选择。 -OfastO3 不要精度的快在-O3基础上再开启-ffast-math允许编译器牺牲浮点精度换取更快的数学运算。⚠️ 金融、控制、传感等对数值敏感的场景禁止使用。三、表格说明选项优化目标执行时间代码大小内存占用编译时间-O0优化编译速度默认---O1/-O兼顾体积和执行---O2更多优化推荐–-O3最高优化慎用—-Os优化代码体积––-OfastO3 牺牲精度—符号含义增加、-减少符号越多幅度越大。四、实战换优化省出 16KB以 测试工程为例做一个最直接的对比默认-O0系统裁剪后固件56.93 KB切换到-O2固件缩小到40.14 KB一次改动体积减少约 29%。在 Flash 只有几百 KB 的单片机上这 16KB 可能就是能不能塞下新功能的差别。// 例一段会被优化掉冗余的循环for(inti0;i100;i){buf[i]0;// -O2 可能被识别为 memset 语义并内联展开}// 优化后机器码更紧凑、执行更快但调试时单步行为会和源码不完全一致建议开发期用-O0保证可调试出 release 时切-O2Flash 吃紧就上-Os。五、选择建议调试中→-O0所见即所得普通发布→-O2稳不会错Flash 紧张→-Os嵌入式首选纯算力且验证过→ 才考虑-O3数值敏感→ 远离-Ofast优化等级不是越高越好适合场景的才是最好的。参考链接gcc -O option flag - RapidTables