std::is_constant_evaluated() 检测当前求值是否处于常量求值过程，而非单纯判断是否在constexpr函数中；它在constexpr函数被非常量上下文调用时返回false，需配合编译期合规代码与运行时兜底逻辑实现双模行为。
std::is_constant_evaluated 是什么，它真能区分编译期和运行时？
它不是“检测当前是否在 constexpr 上下文”，而是“检测当前求值是否发生在常量求值（constant evaluation）过程中”——这是 C++20 的关键语义细节。很多开发者误以为 std::is_constant_evaluated() 在 constexpr 函数里总返回 true，其实不然：当该函数被普通调用（非 consteval、非常量上下文初始化）时，即使函数本身是 constexpr，std::is_constant_evaluated() 仍返回 false。
典型误用场景：
- 在
constexpr函数中直接写if (std::is_constant_evaluated()) { ... }，却用非常量参数调用它 → 分支走运行时逻辑，但开发者预期走编译期分支 - 试图用它替代
consteval强制编译期执行 —— 它不阻止运行时调用，只提供分支依据
怎么写一个真正“编译期优先、运行时不崩溃”的 constexpr 函数？
核心原则：把编译期可做的逻辑放在 std::is_constant_evaluated() 分支内，且确保该分支内所有操作都满足常量求值要求（如不能调用非 constexpr 成员函数、不能用 new、不能读非常量全局变量）；运行时分支则用常规代码兜底。
示例（安全的字符串长度计算）：
立即学习“C++免费学习笔记（深入）”；
constexpr size_t safe_strlen(const char* s) {
if (std::is_constant_evaluated()) {
// 编译期分支：只能用 constexpr 兼容操作
const char* p = s;
while (*p != '\0') ++p;
return p - s;
} else {
// 运行时分支：可用标准库，也可用更高效实现
return std::strlen(s);
}
}注意点：
- 不能在编译期分支调用
std::strlen—— 它不是 constexpr 函数 - 传入的
s必须是字面量字符串或 constexpr 字符数组，否则编译期分支会失败（SFINAE 或硬错误） - 若想支持用户自定义类型，需额外约束
std::is_literal_type_v或 C++23 的std::is_consteval配合
为什么有时候 std::is_constant_evaluated() 在 constexpr 函数里返回 false？
因为 C++ 标准允许编译器对 constexpr 函数做“运行时求值优化”：只要最终结果可确定，编译器可选择不在编译期执行整个函数体。常见触发条件：
- 函数被非常量表达式调用（例如
int x = 42; auto r = safe_strlen(arr[x]);） - 函数参数虽是 constexpr，但函数体内有未被优化掉的运行时依赖（如间接调用虚函数、访问 volatile 变量）
- 使用了某些编译器尚未完全支持常量求值的特性（如部分
std::string_view操作在旧版 GCC 中）
验证方式：把函数调用放在 static_assert 中，如果通过，说明该次调用确实在编译期完成；否则就是运行时求值，std::is_constant_evaluated() 自然为 false。
和 consteval、if consteval 比较：什么时候该用哪个？
consteval 是最严格的：它强制函数**只能**在编译期调用，运行时调用直接报错（编译失败）。而 std::is_constant_evaluated() 是运行时分支机制，适合需要双模行为的场景。
if consteval（C++23）是语法糖，等价于 if (std::is_constant_evaluated())，但语义更清晰，且编译器可对 consteval 分支做更强假设（比如允许更多优化）。不过目前主流编译器对 if consteval 的支持仍不如 std::is_constant_evaluated() 稳定（尤其 Clang 15 前、MSVC 19.32 前）。
选型建议：
- 只需要编译期结果，且不允许运行时 fallback → 用
consteval - 要同一份代码兼顾编译期效率和运行时兼容性 → 用
std::is_constant_evaluated() - 已升级到 C++23 且团队统一工具链 → 可逐步迁移到
if consteval，但注意它不改变底层求值模型，只是语法层封装
最容易被忽略的一点：无论用哪个，分支内的代码仍必须各自满足其求值模型的约束 —— 编译期分支写了个 std::vector 构造，照样编译失败，跟外面套什么条件无关。
