std::is_constant_evaluated() 仅用于区分编译期与运行期上下文，非分支预测优化工具；它在 constexpr 函数中返回 bool 值，不改变汇编或指令顺序，且严禁在 consteval 函数中调用。
std::is_constant_evaluated() 不能“优化分支预测”，它只是让代码能区分编译期和运行期上下文——用错地方反而导致常量求值失败或性能倒退。
为什么 std::is_constant_evaluated() 不是分支预测优化工具
它不改变 CPU 分支预测器行为，也不生成更紧凑的汇编；它只在 constexpr 函数体内返回一个 bool 值，告诉程序员“当前是否正在常量求值”。编译器不会因为它存在就提前折叠分支、消除条件跳转或调整指令顺序。
常见误用现象：consteval 函数里调用 std::is_constant_evaluated() —— 这会直接触发编译错误，因为 consteval 函数**必须且只能**在编译期求值，此时该函数返回值恒为 true，但标准禁止在 consteval 函数中调用它（GCC/Clang 均报错 error: call to 'is_constant_evaluated' is not a constant expression）。
正确配合 consteval 的写法：用 constexpr + is_constant_evaluated()，而非 consteval
想实现“编译期走 A 路径、运行期走 B 路径”，必须用 constexpr 函数（不是 consteval），并在内部用 std::is_constant_evaluated() 分支。编译器会分别处理两条路径：常量求值时只检查 A 路径是否合法；运行时则忽略 A 路径、只编译 B 路径。
立即学习“C++免费学习笔记（深入）”；
-
consteval函数不能含任何运行期逻辑，也不能调用std::is_constant_evaluated() -
constexpr函数可以同时兼容两种上下文，是唯一能用is_constant_evaluated()的场景 - 若 A 路径用了运行期不可用的操作（如
new、std::cout），必须确保它只在is_constant_evaluated() == true时执行，否则常量求值会失败
constexpr int compute(int x) {
if (std::is_constant_evaluated()) {
return x * x; // 编译期：纯算术，OK
} else {
return expensive_runtime_calc(x); // 运行期：可含 I/O、分配等
}
}容易踩的坑：路径不对称导致常量求值静默失败
当 if 分支中某条路径在常量上下文中非法，但编译器没报错，而是直接放弃常量求值、退化为运行时调用——这会让本该在编译期完成的计算延迟到运行期，且毫无提示。
- 典型诱因：
else分支用了std::vector构造、dynamic_cast、或未标记constexpr的第三方函数 - 更隐蔽的问题：分支中调用了模板特化，而该特化未声明为
constexpr，导致整条路径不可常量求值 - 验证方法：对输入字面量调用函数，再用
static_assert(compute(5) == 25)—— 若报错，说明常量分支实际不可达
替代方案：优先用模板 + if consteval（C++23）
C++23 引入了 if consteval，语义更清晰、无歧义，且编译器能更好约束路径合法性：
constexpr int compute(int x) {
if consteval {
return x * x; // 编译期专属，不允许出现运行期操作
} else {
return expensive_runtime_calc(x);
}
}相比 std::is_constant_evaluated()，它强制编译器验证 if consteval 块内所有表达式都满足常量求值要求，出错即报，不退化。旧代码迁移时注意：GCC 13+、Clang 16+ 支持，MSVC 2022 17.5+ 支持。
真正关键的不是选哪个语法，而是意识到：分支逻辑是否能在两个上下文里各自成立，比怎么写条件本身重要得多。
