最可靠的是clang命令行直接加-O2或-O3；-O2安全稳定适合生产，-O3更激进但可能增大体积或引发问题；CMake中应设CMAKE_BUILD_TYPE=Release以自动启用优化和-DNDEBUG。
clang命令行直接加-O2或-O3最可靠
Clang没有“开启优化”的开关按钮，它靠显式传参生效。不加任何-O选项时，默认是-O0（无优化），哪怕你什么都没写，也得手动告诉它要优化。
最常用且稳妥的是-O2：启用绝大多数安全优化，比如函数内联、循环展开、指令重排，编译时间可控，生成代码稳定，适合绝大多数生产场景。
-
-O3比-O2多开向量化、更激进的函数展开，但可能增大二进制体积，某些边界case下反而变慢或触发未定义行为 -
-Ofast会绕过IEEE浮点规则（比如把a + b - b直接简化为a），除非你明确知道后果，否则别用 -
-Os专为体积优化，适合嵌入式或资源受限环境，不是性能优先的选择
CMake里设CMAKE_BUILD_TYPE=Release才真正生效
很多人在CMakeLists.txt里写set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O2")，这看似能用，但实际容易出问题：CMake缓存不会自动刷新，改了之后不清理构建目录，旧flag仍被沿用；而且它覆盖不了工具链默认设置，尤其跨平台时不可靠。
正确做法是在配置阶段指定构建类型：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
立即学习“C语言免费学习笔记（深入）”；
- 命令行运行：
cmake -DCMAKE_BUILD_TYPE=Release .. - 这个
Release会触发CMake内置逻辑，自动给CMAKE_C_FLAGS加上-O3 -DNDEBUG（不是-O2） - 如果项目需要
-O2而非-O3，应在set(CMAKE_C_FLAGS_RELEASE ...)中覆盖，而不是硬塞进CMAKE_C_FLAGS
别忘了-DNDEBUG，否则assert()还在跑
优化级别本身不关掉assert()——这是个宏控制行为，和-O无关。如果你用了assert(x > 0)，即使开了-O3，只要没定义NDEBUG，这段检查依然执行，拖慢速度还可能掩盖逻辑错误。
- 单独加
-DNDEBUG即可禁用所有assert，这是Release构建的标配 - 不要依赖
#define NDEBUG写在源码里，那会污染头文件、难维护 - 和
-O3搭配写成clang -O3 -DNDEBUG -o app app.c才是完整Release组合
-g和优化共存？小心调试信息失效
想边优化边调试？可以加-g，但要注意：-O2 -g没问题，-O3 -g可能导致部分变量在调试器里显示为<optimized out></optimized>，因为编译器做了寄存器分配或内联，原始变量已不存在。
- 这不是bug，是优化的自然结果；GDB/LLDB对
-O2支持更好 - 真要深度调试，建议先用
-O0 -g定位问题，再切回-O2 -g验证修复效果 - 发布包绝对不要带
-g，符号表会显著增大二进制体积，且暴露内部结构
实际构建时，最容易被忽略的是-DNDEBUG和构建类型联动——CMake里设了Release却不检查是否真传进了-DNDEBUG，或者手写命令漏掉它，结果程序跑得慢还报奇怪断言失败。优化不是只调一个参数的事。
