[[likely]]和[[unlikely]]是编译器提示属性，仅影响机器码布局以优化分支预测失败开销，不改变程序行为；必须紧贴复合语句左大括号使用，适用于错误处理等低频路径，需用perf验证效果。
![c++ [[likely]]和[[unlikely]]怎么优化分支预测（c++20）](https://img.php.cn/upload/article/001/221/864/179333862233189.png)
[[likely]] 和 [[unlikely]] 不是魔法，只是给编译器递个纸条
它们不改变程序行为，也不强制 CPU 怎么预测，只影响生成的机器码布局：编译器会把 [[likely]] 标记的分支代码尽量放在紧邻跳转指令之后的“直线路径”上，减少取指时的跳转开销；而 [[unlikely]] 分支则被挪到稍远的位置，甚至可能放到函数末尾附近。这能降低分支预测失败时流水线清空（pipeline flush）的代价——尤其在热循环或内核关键路径里，省下的几个周期会累积成可观收益。
必须紧贴语句块开头，语法错就直接报错
常见写法错误包括：if (x) [[likely]] { ... }（属性位置错）、[[likely]] if (x) { ... }（修饰对象错）、或者写在 else 前但没配对。正确姿势只有一种：
if (ptr == nullptr) [[unlikely]] {
return -1;
}
// 或
if (size > 0) [[likely]] {
process(data, size);
}
-
[[likely]]/[[unlikely]]必须直接修饰一个复合语句（即带花括号的块），不能修饰if关键字本身 - 它只能出现在语句块的左大括号
{前，且中间不能有换行或空格干扰（某些旧版 Clang 对格式敏感） - 在
else分支上用时，要确保和前面的if形成完整结构，比如else [[unlikely]] { ... }
别乱标，概率偏差大时反而拖慢性能
编译器在 -O2/-O3 下本就会基于 profile-guided optimization（PGO）数据自动优化分支布局。[[likely]] 这类提示只有在你**比编译器更清楚运行时分布**时才有价值。典型适用场景：
- 错误处理路径：如
if (errno != 0) [[unlikely]] { handle_error(); } - 边界检查失败：如
if (idx >= vec.size()) [[unlikely]] { throw std::out_of_range(""); } - 设备未就绪、锁争用失败等低频系统事件
反例：用户输入校验、配置开关、调试日志开关——这些分支概率高度依赖外部输入，硬标 [[unlikely]] 可能让编译器放弃更优的 PGO 布局，实测反而变慢。
立即学习“C++免费学习笔记（深入）”；
效果得用 perf 验证，光看编译结果没用
加了属性不代表一定生效。GCC/Clang 在不同优化级别下对属性的支持程度不同，某些目标架构（如 ARM64）可能忽略它。真正要看的是运行时指标：
- 用
perf stat -e branches,branch-misses ./a.out对比前后分支失误率 - 用
perf record -e cycles,instructions,br_inst_retired.all_branches ./a.out看指令吞吐变化 - 反汇编确认热路径是否真的被放到了顺序地址段：
objdump -d ./a.out | grep -A10 "your_function_name"
最容易被忽略的一点：这些属性只在编译器实际生成跳转指令时起作用。如果条件表达式能被常量折叠（比如 if (true)），或者被 LTO 全局优化掉，那 [[likely]] 就彻底没机会出场了。
