std::is_constant_evaluated() 是运行时环境返回 false、常量求值环境返回 true 的信号函数，不触发分支剪枝，两分支均需满足 constexpr 约束。
std::is_constant_evaluated() 不是编译器优化开关
它不会让编译器自动把运行时代码“提升”到编译期，也不会触发分支剪枝；它只是一个运行时求值环境下恒为 false、常量求值环境下返回 true 的信号函数。你写 if (std::is_constant_evaluated()) { ... }，两个分支的代码仍会被完整解析和语义检查——哪怕条件在编译期已知为真或假。
常见错误现象：constexpr 函数里在 else 分支调用 std::printf 或 new，导致整个函数无法用于 static_assert 或模板参数，因为编译器必须确保所有路径语法合法、且不违反 constexpr 约束。
- 它只在
constexpr或consteval函数体内有意义；在普通函数中调用，行为未定义或恒返回false - 返回值完全取决于**调用点上下文**：比如
int arr[foo()]中的foo()被强制常量求值 → 返回true；而auto x = foo();通常走运行时 → 返回false - 不能替代
if constexpr：后者基于编译期常量表达式做模板级剪枝，前者基于执行环境做逻辑分发
编译期分支必须 100% constexpr 兼容
一旦进入 std::is_constant_evaluated() 为 true 的分支，所有操作都必须满足 C++20 常量求值规则：不能调用非 constexpr 函数（如 std::strlen、std::sqrt），不能使用 new / delete（C++23 部分支持但跨编译器不稳定），不能读取非常量全局变量，也不能对未初始化对象取地址。
常见错误现象：在 true 分支里写 std::vector<int> v{1,2,3};</int> —— GCC 14 可能允许，Clang 18 要求显式 constexpr 构造器，MSVC 19.39 直接报错。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：把编译期逻辑抽成独立
constexpr辅助函数，例如constexpr_size_t literal_strlen(const char*) - 避免在分支内依赖运行时设施：如
std::array::data()在某些标准库实现中非 constexpr，改用指针算术 - 对用户自定义类型，需额外检查
std::is_literal_type_v<T>或 C++23 的std::is_consteval约束
运行时分支别反向污染编译期路径
运行时分支可以自由使用 std::string、std::vector、系统调用等，但它的存在本身会影响整个函数能否被用于常量表达式。只要该分支含任何非法 constexpr 操作（哪怕永远不会执行），整个 constexpr 函数就失去参与编译期计算的资格。
常见错误现象：函数声明为 constexpr，但在 else 分支里写了 std::cout << "debug" —— 导致 static_assert(foo() == 42) 编译失败，因为 std::cout 不是 constexpr 上下文允许的操作。
- 推荐解耦：把运行时逻辑移到一个非
constexpr的私有辅助函数中，主函数只做跳转 - 不要在
else分支里做“兜底断言”或日志输出——这些不是 constexpr 兼容操作 - 若需调试，用宏守卫，例如
#ifndef NDEBUG包裹运行时打印，确保 release 构建中该分支彻底消失
Clang/GCC/MSVC 对常量求值路径判定不一致
是否触发常量求值，取决于编译器对调用点语义的判定强度。例如 constinit 变量初始化，GCC 可能更激进地尝试常量求值，Clang 更保守；而 MSVC 对 C++23 constexpr 动态内存分配支持几乎为零。
常见错误现象：同一段代码在 GCC 上 std::is_constant_evaluated() 返回 true 并成功编译，在 Clang 上却报 “call to non-constexpr function”，或始终返回 false。
- 验证方式：把调用放在
static_assert或数组大小中，这是最可靠的常量求值触发点 - 避免依赖隐式上下文：比如普通
const变量初始化、函数参数默认值，不同编译器行为差异大 - CI 构建中建议固定编译器版本，并在关键路径加
static_assert(std::is_constant_evaluated(), "...")显式断言预期行为
