std::is_constant_evaluated 什么时候返回 true
它只在编译期求值的上下文中返回 true，比如 constexpr 函数体内、且该函数正被用于需要常量表达式的场景（如数组大小、模板非类型参数、static_assert 条件）。不是所有 constexpr 调用都会触发它——运行时调用同一个函数时，std::is_constant_evaluated() 返回 false。
常见错误是以为加了 constexpr 函数就“自动进编译期”，其实取决于调用方式：
- 用在
int arr[std::my_func()]中 → 编译期执行 →std::is_constant_evaluated()为true - 赋值给普通变量：
auto x = std::my_func();→ 可能运行时执行 → 返回false - 即使函数体里写了
if (std::is_constant_evaluated()) { ... }，分支本身不改变求值时机，只是让你有条件地选择逻辑
怎么写一个安全的 constexpr 分支逻辑
典型用途是：同一份代码，编译期走轻量路径（比如查表、递归展开），运行时走通用路径（比如循环、系统调用）。关键在于别让运行时路径依赖编译期限定的特性（比如 std::array::data() 在 constexpr 上下文可能不可用）。
示例（计算字符串字面量长度）：
立即学习“C++免费学习笔记（深入）”；
constexpr size_t str_len(const char* s) {
if (std::is_constant_evaluated()) {
const char* p = s;
while (*p) ++p;
return p - s;
} else {
return std::strlen(s); // 运行时才调用
}
}注意点：
- 两个分支必须都满足
constexpr函数的语法约束（比如不能有new、不能调用非constexpr函数），否则整个函数无法声明为constexpr -
std::strlen不是constexpr，所以它只能出现在else分支里，且该分支不会在编译期执行 - 不要在
if分支里写运行时专属操作（如std::cout ），编译器会报错
为什么有时候 std::is_constant_evaluated() 总是 false
最常见原因是：你没把它用在真正需要常量表达式的地方。编译器不会“主动”把 constexpr 函数拉进编译期，而是按需决定。
典型误判场景：
- 函数参数不是字面量或
constexpr变量（比如传入argv[1]或用户输入）→ 必然运行时执行 - 目标上下文不要求常量（如初始化
int x = f();）→ 即使f是constexpr，编译器可自由选择执行时机 - 用了 C++20 之前的编译器（GCC std::is_constant_evaluated 不可用或行为不一致
- 函数被标记为
consteval→ 它强制编译期执行，但此时std::is_constant_evaluated()没意义（永远true），也不推荐混用
和 consteval、constexpr 的关系与取舍
std::is_constant_evaluated() 是“柔性”方案；consteval 是“刚性”方案。前者允许一份函数适配两种环境，后者彻底放弃运行时可能性。
选哪个？看需求：
- 要兼容旧代码、或必须支持运行时 fallback（比如日志函数编译期生成字符串字面量，运行时拼接）→ 用
constexpr+std::is_constant_evaluated() - 逻辑天然只能编译期完成（比如生成哈希值作为 NTTP）→ 直接用
consteval，更清晰、错误提示更早 - 别在
consteval函数里调用std::is_constant_evaluated()—— 标准未定义行为，Clang 会警告，GCC 可能静默忽略 - 性能上无差别：分支判断本身零开销，编译器在常量求值阶段就已确定走哪条路
真正容易被忽略的是：这个函数不是用来“探测是否在 constexpr 环境”，而是“探测当前这次调用是否正在被用于常量表达式”。它回答的不是“我在哪儿”，而是“我为什么被调用”。
