std::is_constant_evaluated() 仅在 constexpr 或 consteval 函数中有效，普通函数中调用行为未定义（实际返回 false）；其作用是区分编译期/运行时求值路径，但分支优化取决于各分支内代码是否满足对应阶段约束，而非该函数本身触发优化。
std::is_constant_evaluated() 不是编译器优化开关，它不触发自动内联、常量传播或死代码消除；它只在 constexpr 函数中提供一个运行时不可知的分支信号——编译器是否正处在常量求值路径上。用错地方，它连一行汇编都优化不了。
为什么 std::is_constant_evaluated() 在普通函数里永远返回 false
它只能在 constexpr 或 consteval 函数体内有意义。在普通函数里调用，行为未定义（GCC/Clang 实际返回 false），且编译器不会为你剪掉任何分支。
- 写
int f() { return std::is_constant_evaluated() ? 1 : 0; }→ 永远返回0，且该if分支无法被优化掉（不是常量表达式） - 写
constexpr int f() { return std::is_constant_evaluated() ? 1 : 0; }，再用在static_assert(f() == 1);中 → 编译期执行，返回1 - 同个
constexpr函数，若调用点是int x = f();→ 运行时调用，std::is_constant_evaluated()返回false
怎么写出真正能被编译器“吃掉”的编译期分支
关键不在 if，而在每个分支里的操作是否满足当前求值阶段的约束。编译器只有确认某分支“合法且可达”，才可能生成对应代码；否则直接报错或拒绝编译。
- 编译期分支（
if (std::is_constant_evaluated())内）只能用：constexpr函数、字面量、static_assert、std::array、纯循环展开逻辑 - 禁止出现：
new、std::strlen、std::cout、对非常量全局变量取地址、非constexpr成员函数调用 - 运行时分支（
else）可自由使用标准库，但别把它定义的变量传进编译期分支（比如在else里构造std::string，再试图用它的c_str()去喂编译期逻辑） - 推荐拆成两个独立函数：
constexpr版本 + 普通函数版本，主函数只做跳转，避免混合语义
Clang 和 GCC 对“隐式常量求值”的判定差异在哪
是否进入常量求值路径，取决于编译器对调用点上下文的语义判定。这不是 bug，而是标准留白：C++ 只规定“必须支持常量求值”，没规定“必须尽可能多做”。
立即学习“C++免费学习笔记（深入）”；
- GCC 12+ 在
constinit初始化、某些模板参数推导中更激进，可能让std::is_constant_evaluated()返回true - Clang 更保守，通常只在明确强制场景（
static_assert、数组大小、consteval调用）中返回true - 验证唯一可靠方式：
static_assert(my_func() == 42);能过 → 说明这次调用确实在编译期完成；否则就是运行时，std::is_constant_evaluated()必为false - 跨平台项目应以 Clang 行为为底线，别依赖
const变量初始化这类模糊上下文
最容易被忽略的不是语法怎么写，而是分支合法性检查——编译器不会帮你“宽容执行”，它只认规则。哪怕只在 if 分支里写了一行 std::printf，整个 constexpr 函数就废了，不管 else 多干净。
