std::is_constant_evaluated() 只在编译器判定需常量表达式的上下文中才返回 true，如 static_assert 或数组大小；普通调用、非字面量参数、旧标准或未强制常量求值时均返回 false。
它只在真正进入常量求值路径时返回 true，其他情况基本都返回 false——这不是 bug，是设计使然。想靠它“自动加速”运行时代码，注定失败。
为什么 std::is_constant_evaluated() 总是 false
最常见原因是：调用点没被编译器判定为“需要常量表达式”。哪怕函数声明为 constexpr，只要上下文不要求编译期结果，分支就进不去编译期逻辑。
常见错误现象：
-
int x = my_func();→ 运行时调用，std::is_constant_evaluated()返回false -
static_assert(my_func() == 42);或int arr[my_func()] = {};→ 强制常量求值，才可能返回true - 传入参数不是字面量或
constexpr变量（比如argv[1]、用户输入、运行时读取的配置）→ 必然走运行时分支 - 用了 C++17 或更早标准 →
std::is_constant_evaluated根本不可用，GCC/Clang 会报未定义引用
constexpr 函数里怎么安全写分支
关键不是“能不能写 if”，而是“每个分支里的操作是否合法”。编译期分支里一旦出现运行时专属操作，直接编译失败。
立即学习“C++免费学习笔记（深入）”；
编译期分支（if (std::is_constant_evaluated()) 内）只能用：
-
constexpr函数、字面量、static_assert、std::array、纯循环展开逻辑 - 不能出现：
new、std::strlen、std::cout、对非常量全局变量取地址、非constexpr成员函数调用 - 运行时分支（
else）可自由使用标准库和动态资源，但别反向污染编译期分支——比如在else里定义一个std::string，再试图把它传进编译期分支 - 推荐把两套逻辑拆成独立辅助函数：
constexpr版本专供编译期，普通函数版负责运行时，主函数只做跳转
为什么 clang/gcc 行为有时不一致
是否进入常量求值路径，取决于编译器对调用点的语义判定，而不同版本对“隐式常量求值”的激进程度不同。比如某些 GCC 版本会在 constinit 变量初始化中更积极地尝试常量求值，而 Clang 可能更保守。
常见错误现象：代码在 GCC 上编译通过并返回 true，换 Clang 就报错“call to non-constexpr function”，或始终返回 false。
验证方式唯一可靠：用 static_assert 包裹调用，通过即说明该次执行确实在编译期完成；否则就是运行时，std::is_constant_evaluated() 必为 false。
别依赖未明确要求常量表达式的上下文（如普通 const 变量初始化），跨平台项目应以 Clang 的行为为底线。
它本质是个元编程信号，不是运行时性能开关。最容易被忽略的一点是：编译器不会因为 if 条件在编译期已知为 true 就跳过对 else 分支的语法和语义检查——两个分支都必须各自合法，否则整个函数无法用于常量求值上下文。
