std::is_constant_evaluated() 仅在明确需要常量表达式的上下文中返回 true，如 static_assert 或数组大小；const 变量初始化、非常量参数或旧标准下均返回 false，唯一可靠验证是 static_assert 或变长数组测试。
它不能让运行时代码变快，但能让你在同一个 constexpr 函数里，安全地为编译期常量和运行时变量提供两套互不干扰的实现——前提是调用点真被编译器当作常量表达式求值；否则分支永远进不去，还可能拖慢编译。
为什么 std::is_constant_evaluated() 总是返回 false
这不是 bug，是设计使然：它只在明确需要常量表达式的上下文中才可能为 true。常见误判场景包括：
-
int x = my_func();→ 普通变量初始化，不强制常量求值，必为 false -
const int y = my_func();→const不等于constexpr，标准不要求走编译期 - 传入参数含
argv[1]、std::cin >> x或任何非常量值 → 整个调用退化为运行时 - 用 C++17 或更早标准 →
std::is_constant_evaluated根本不存在，链接失败
唯一可靠验证方式：用 static_assert(my_func() == 42); 或 int arr[my_func()] = {};。通不过，就说明没进编译期路径。
编译期分支里写什么会直接编译失败
一旦进入 if (std::is_constant_evaluated()) 分支，所有语句都必须满足 C++20 常量求值规则。常见非法操作：
立即学习“C++免费学习笔记（深入）”；
- 调用
std::strlen、std::printf、std::sqrt等非constexpr函数 - 使用
new、delete（C++23 部分支持但跨编译器不稳定） - 读取非常量全局变量或未初始化的
static变量 - 对局部变量取地址（除非该变量已初始化且生命周期可静态验证）
- 调用非
constexpr成员函数，或使用std::vector::push_back（即使 C++23 允许，GCC 14 仍限制 trivial 类型）
安全替代方案：把编译期逻辑抽成独立 constexpr 辅助函数，比如 constexpr_size_t literal_strlen(const char*)，主函数只做跳转。
怎么写出真正可用的双模数学函数（以整数幂为例）
高性能库中，小指数（如 pow(x, 2)）适合编译期展开，大指数或浮点数必须交给 std::pow。关键不是“能不能”，而是“分得干净、不越界”：
- 函数签名必须带
constexpr，哪怕运行时分支用了std::sqrt - 必须用普通
if，不是if constexpr—— 后者要求条件本身是常量表达式，而std::is_constant_evaluated()不是 - 运行时分支可以自由使用
std::string、std::vector、IO，但它的存在本身会让整个函数失去参与static_assert的资格，如果里面混了非法操作 - 推荐结构：
constexpr int ipow(int base, int exp) { if (std::is_constant_evaluated()) { // 编译期：仅用字面量、循环展开、递归 constexpr 函数 return exp == 0 ? 1 : base * ipow(base, exp - 1); } else { // 运行时：可调用 std::pow、做范围检查、抛异常 return static_cast<int>(std::pow(base, exp)); } }
注意：递归深度受编译器限制（GCC 默认约 512 层），编译期分支若递归过深，会触发 constexpr evaluation depth exceeded。
clang 和 gcc 行为不一致时怎么办
差异根源在于：哪个调用点“算作常量求值”，不同编译器判断尺度不同。尤其在 constinit 初始化、模板非类型参数推导等边界场景下：
- GNU GCC 12+ 对隐式常量求值更激进，某些
constinit初始化也可能触发true - Clang 更保守，通常只在
static_assert、数组大小、consteval调用中返回true - MSVC 行为更接近 Clang，但部分 C++23 特性支持滞后
跨平台项目应以 Clang 的行为为底线，别依赖未明确要求常量表达式的上下文（如普通 const 变量初始化）。最稳妥做法：把两套逻辑拆成两个独立函数，主函数只做跳转，避免分支合法性检查成为编译器兼容性瓶颈。
真正容易被忽略的复杂点是：分支合法性检查发生在编译期，且是硬性约束——即便你只打算在运行时用，编译器仍要完整解析、展开、诊断所有 constexpr 分支里的表达式。一旦分支内含复杂模板或递归 constexpr 算法，编译时间会明显上升。
