__builtin_expect 是 gcc/clang 提供的分支预测提示指令，不加速分支本身，而是指导编译器优化指令布局以减少流水线冲刷；需正确使用 __builtin_expect(expr, expected)，预期值为 0 或 1，常配合 !!x 和 [[gnu::cold]] 提升效果。
__builtin_expect 是什么，它真能加速代码？
它不能直接让分支变快，只是告诉编译器“这个条件大概率是 true 还是 false”，帮编译器把更可能执行的路径放在指令流前面，减少 CPU 分支预测失败带来的流水线冲刷。实际效果高度依赖硬件、分支概率和编译器优化级别（-O2 或 -O3 才会真正生效）。
常见错误现象：__builtin_expect(x, 1) 写成 __builtin_expect(1, x) —— 参数顺序反了，第二个参数才是“预期值”，必须是 0 或 1；传其他值（比如 2）不会报错，但行为未定义。
-
__builtin_expect只影响生成的汇编布局，不改变逻辑，也不做运行时检查 - 只在 GCC 和 Clang 中可用，MSVC 不支持（别试图用
#ifdef __GNUC__包一层就当可移植） - 对恒定条件（如
if (true)）或编译器能静态推导的分支，加不加都一样——编译器早就优化掉了
怎么写才不白写：典型使用模式和参数陷阱
最常见用途是优化错误处理路径（比如系统调用失败、内存分配失败），因为这些情况本就不该频繁发生。关键不是“加 __builtin_expect”，而是加在**最外层条件判断上**，且预期值要符合真实热路径。
错误示例：if (__builtin_expect(ptr == nullptr, 0)) { ... } —— 这里 ptr == nullptr 是表达式，返回 bool，但 __builtin_expect 要求第一个参数是整型，C++ 中 bool 隐式转 int 没问题，但语义易混淆。更清晰写法是：
if (__builtin_expect(!!ptr, 1)) { /* 正常路径 */ }
else { /* 错误路径 */ }
- 永远用
!!x或(x) ? 1 : 0确保第一个参数是明确的整数值，避免隐式转换歧义 - 预期值写
1表示“这里大概率成立”，写0表示“这里大概率不成立”——别按中文语序反着记 - 不要嵌套用：
if (__builtin_expect(__builtin_expect(x, 1), 1))没意义，编译器不认第二层
和 if/else 布局、attribute((cold)) 怎么配合？
单靠 __builtin_expect 效果有限。现代写法通常是组合技：把低概率分支显式标为冷函数，再配合预期提示，让编译器更激进地把冷代码挪到 .text.unlikely 段。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
例如系统调用失败处理：
if (__builtin_expect(ret
-
[[gnu::cold]]或__attribute__((cold))告诉编译器：这个函数极少调用，优先把它从热代码段移走 - 和
__builtin_expect一起用时，__builtin_expect影响分支跳转目标布局，cold影响函数体位置，二者互补 - 注意：C++17 起推荐用
[[likely]]/[[unlikely]]替代（GCC 9+、Clang 10+ 支持），写法更直观：if (ptr) [[likely]] { ... }
性能差异到底有多大？别测错场景
在循环内高频分支（比如解析器状态机、网络包分类）中，正确使用可能带来 5%–15% 的吞吐提升；但在一次性的初始化逻辑或内存访问瓶颈明显的代码里，基本测不出差别，甚至因代码膨胀反而略慢。
容易踩的坑：
- 用
std::chrono在 debug 模式下测——-O0下__builtin_expect完全不生效，结果毫无参考价值 - 没关 ASLR、没绑核、没禁用 CPU 频率调节，导致测量抖动远大于优化收益
- 拿 microbenchmark 测单个 if，忽略了真实函数调用上下文（寄存器压力、cache line 撞击等）
真正值得加的地方很窄：你知道这个分支概率 >95% 或
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
