-O系列参数必须显式指定级别才有效，-O等价于-O1；-O0无优化，-O1基础优化，-O2平衡推荐，-O3激进可能出错，-Os减小体积；-O与-g可共用，-Og专为调试设计；生产环境需搭配-march、-flto、-Werror等约束选项。
-O 系列参数是 GCC 开启优化的唯一标准方式，不是加个 flag 就能“开启优化”，必须明确指定级别，否则 -O 不生效（等价于 -O0，即无优化）。
怎么写 -O 参数才有效
直接写 gcc -O main.c 是最简写法，但实际效果等同于 -O1；更常见、更稳妥的做法是显式指定数字：
-
-O0：完全关闭优化，编译最快，调试最友好（变量值、执行顺序与源码一致） -
-O1：启用基础优化（如常量折叠、死代码删除），编译速度影响小 -
-O2：推荐日常使用，开启内联、循环展开、寄存器分配等，平衡性能与稳定性 -
-O3：激进优化（如自动向量化、跨函数内联），可能引入边界 case 行为变化，某些旧代码会出错 -
-Os：优先减小代码体积，适合嵌入式或加载敏感场景（不等价于-O2 -s）
示例：
gcc -O2 -Wall main.c -o main
注意：-O2 必须放在源文件和 -o 之前，位置不影响，但不能被其他选项“遮挡”——比如写成 gcc main.c -O2 -o main 完全没问题，但 gcc main.c -o main -O2 也合法（GCC 允许参数后置）。
-O 和 -g 能一起用吗
能，而且很常用，尤其在开发阶段需要兼顾调试与性能验证时：
-
-g生成调试符号，-O2同时做优化，GDB 仍可设断点、看变量（但部分优化后变量可能被寄存器覆盖或消除，print var可能报optimized out） - 若要避免
optimized out，可用-Og（GCC 4.8+ 支持）：专为调试设计的优化级别，保留完整调试体验的同时做轻量优化 -
-O3 -g组合风险更高——某些内联或重排可能导致断点跳转异常，不建议日常调试使用
容易踩的坑：-O 后面没跟数字 or 拼错
这些写法看似合理，实则无效或危险：
-
gcc -O main.c→ 实际是-O1，但容易误以为“开了优化”就万事大吉，而没意识到它比-O2少很多关键优化 -
gcc -o2 main.c→ 编译器当作输出文件名o2处理，根本没触发优化，最后生成的是未优化的o2可执行文件 -
gcc -O 2 main.c→-O和2被识别为两个独立参数，优化未启用（GCC 不接受空格分隔的-O和数字） -
gcc -O3 -fno-tree-vectorize main.c→ 显式关掉某项子优化，但容易忽略-O3还启用了其他隐式开关（如-funroll-loops），行为不可控
生产环境推荐组合
真正上线前的构建，光靠 -O2 或 -O3 不够，需配合约束性选项防止意外：
-
-O2 -march=native -mtune=native：针对本机构建，性能最好，但生成的二进制不能直接复制到老 CPU 上运行 -
-O2 -march=x86-64：保证最低 x86-64 兼容性，适合分发通用 Linux 包 -
-O2 -flto：启用链接时优化，跨 .o 文件做全局优化，但需全程用-flto（编译和链接都要加） - 绝对不要在生产构建中漏掉
-Werror—— 优化可能暴露新警告，不拦截会导致静默降级
优化不是越高级越好，而是要和你的测试覆盖度、目标平台、交付要求对齐。一个没测过 -O3 的模块，上线前切回 -O2 是最省心的选择。
