CMAKE_BUILD_TYPE=Release必须首次配置时传入，仅对单配置生成器有效；重复运行cmake不会更新该值，需清空缓存或重建build目录；Clang手动Release需显式指定-O2 -DNDEBUG -g0并验证无debug段。
cmake -DCMAKE_BUILD_TYPE=Release 必须在首次配置时传入
Clang 本身不决定 Release 还是 Debug，真正起作用的是构建系统（比如 CMake）传给编译器的标志。用 Clang 做后端时，CMAKE_BUILD_TYPE 是控制开关——但它只在 配置阶段 生效，且仅对单配置生成器（Makefile / Ninja）有效。
常见错误：先运行 cmake .. 生成了 Debug 版本，再补加 -DCMAKE_BUILD_TYPE=Release 重跑 cmake，结果还是 Debug。这是因为缓存已锁定 CMAKE_BUILD_TYPE 值，后续传参被忽略。
- 正确做法：删掉整个 build 目录，或执行
cmake -U清空缓存，再从头运行cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ .. - 如果用 Ninja，确认
build.ninja里出现了-O3和-DNDEBUG，而不是-g -O0 - Windows + Visual Studio 生成器是多配置的，此时
CMAKE_BUILD_TYPE无效，得用--config Release配合cmake --build
Clang 编译命令行怎么手动指定 Release 模式
绕过 CMake 直接调用 clang++ 时，Release 的核心是两件事：关调试信息、开优化。不能只写 -O2 就完事，还得确保没带 -g，否则调试符号会混进发布二进制里。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 最小 Release 编译命令：
clang++ -std=c++17 -O2 -DNDEBUG -Wall -Wextra main.cpp -o main -
-O2是 Release 常用档位；-O3可能引入不稳定向量化，上线前需实测 -
-DNDEBUG必须显式加上，否则assert()不会被剔除，影响性能和体积 - 避免
-g或-ggdb出现在命令中——哪怕只是残留的 shell history 也得检查
为什么用了 -O2 还是看到调试符号？
不是所有 -O2 都干净。某些发行版预编译的 Clang（如 Ubuntu 的 clang-14）默认启用了 -grecord-gcc-switches，它会悄悄把编译参数写进 DWARF 的 .comment 段。虽然不影响运行，但 file main 会显示 “with debug_info”，CI 流水线可能报错。
- 检查是否真无调试段：
readelf -S main | grep debug，输出为空才可信 - 彻底禁用所有调试信息：加
-g0（注意是零，不是字母 o），它会覆盖任何隐式-g - 验证最终体积：
strip --strip-all main后大小应明显小于未 strip 的版本
Windows 下 Clang + MSVC 工具链的 Release 注意点
Clang on Windows 默认走 MSVC 兼容模式（target x86_64-pc-windows-msvc），这时 Release 不只是加 -O2，还涉及运行时库链接方式。
- 必须指定
/MD（动态链接 Release CRT），而非/MT（静态链接），否则部署时缺vcruntime140.dll - CMake 中设置：
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreadedDLL") - 命令行等价写法：
clang++ --target=x86_64-pc-windows-msvc -O2 -DNDEBUG /MD main.cpp -o main.exe - 别依赖
clang++.exe --version输出里的Thread model: posix——那是误导，实际行为由--target决定
rm -rf build 和 clang++ --target=help 多看两眼，省去半天排查。 
