std::is_constant_evaluated() 在运行时返回 false 是正常现象，它仅在编译期常量求值环境下返回 true，且必须用于 constexpr 或 consteval 函数内配合常量表达式调用才有效。
std::is_constant_evaluated 在运行时返回 false 是正常现象
这个函数只在编译期求值（consteval 函数体、constexpr 函数中被常量表达式调用的分支）里返回 true；只要进入普通运行时路径，它必然返回 false。很多人误以为加了 if (std::is_constant_evaluated()) 就能“自动加速”，其实它不改变执行逻辑，只帮你做分支选择。
- 常见错误：在非 constexpr 函数里调用它，还指望分支能被编译器提前剪掉 —— 不会，此时它就是个固定返回
false的普通函数调用 - 正确场景：仅用于
constexpr或consteval函数内部，配合不同实现路径（比如查表 vs 计算） - 参数差异：它无参数，也不接受任何上下文；它的行为完全取决于当前求值环境是否为「常量求值」，和变量、模板参数无关
热点路径优化必须配合 constexpr 函数 + 编译期输入
想让 std::is_constant_evaluated() 发挥作用，函数本身得是 constexpr，且调用点传入的是字面量或常量表达式。否则分支永远走不到编译期分支，白写。
- 示例有效写法：
constexpr int fast_pow(int base, int exp) { if (std::is_constant_evaluated()) { // 编译期展开幂运算（如 exp=3 → base*base*base） int r = 1; for (int i = 0; i < exp; ++i) r *= base; return r; } else { // 运行时用快速幂，避免循环开销 return quick_pow_runtime(base, exp); } } - 无效调用：
int x = 5; fast_pow(x, 3);——x不是常量表达式，整个调用退化为运行时，std::is_constant_evaluated()返回false - 性能影响：编译期分支若触发，生成的是硬编码结果（零运行时开销），但会增大目标代码体积；运行时分支不受影响
Clang/GCC 对 consteval 函数内 is_constant_evaluated 的处理更严格
在 consteval 函数里调用 std::is_constant_evaluated()，它一定返回 true，但编译器行为有差异：
- Clang 15+：允许你在
consteval函数里写if (!std::is_constant_evaluated())，但该分支永不执行，部分版本会直接报错（“control reaches end of consteval function”） - GCC 12+：对分支剪枝更激进，如果某分支被证明不可达，可能省略诊断；但若分支含非法操作（如
new），仍会报错 - 兼容性风险：MSVC 19.3x 对
consteval+std::is_constant_evaluated()组合支持不稳定，建议用constexpr替代consteval保底
别把它当运行时性能开关，它本质是编译期元编程信号
它不是 __builtin_constant_p 那种可被编译器用于优化决策的内置谓词，而是一个标准库提供的、语义明确的“此刻是否在常量求值中”的询问接口。你不能靠它触发自动向量化或内联策略调整。
立即学习“C++免费学习笔记（深入）”；
- 容易踩的坑：试图在非 constexpr 上下文中依赖它做运行时分支预测（比如缓存策略切换），结果发现分支预测失败率没变，还多了一次函数调用开销
- 真正起效的前提：调用链全程可被编译器判定为常量表达式（包括所有参数、中间变量、模板实参）
- 调试技巧：加
static_assert(std::is_constant_evaluated(), "should be const-evaluated");快速定位哪一环断了常量性
它只在“编译期能确定全部输入”的狭窄条件下才有意义，一旦涉及用户输入、文件读取、系统时钟，就彻底退出舞台。
