std::is_constant_evaluated()是C++20唯一标准、可靠区分编译期与运行期求值的函数，返回bool，只能在函数体内直接调用，用于实现constexpr兼容运行时的双路径逻辑。
std::is_constant_evaluated() 是 C++20 引入的唯一可靠方式，用于在函数体内区分当前调用是否发生在编译期（consteval / constexpr 上下文）还是运行期。它不依赖宏、不靠编译器扩展，是标准规定的“真相开关”。
什么时候必须用 std::is_constant_evaluated()
当你写一个既想支持 constexpr 又要兼容运行时行为的函数，并且两种路径需要不同逻辑（比如编译期查表 vs 运行时查哈希），就不能只靠 if constexpr —— 因为后者在非 constexpr 函数里根本不能用。这时就得靠 std::is_constant_evaluated() 做运行时判断（注意：它在编译期求值，但语法上是普通 if）。
- 典型场景：实现一个“尽量编译期算完，不行就退化到运行时”的字符串哈希函数
- 错误做法：用
#ifdef __GNUC__或__builtin_constant_p—— 非标准、不可移植 - 它返回
bool，且只能在函数体内直接调用，不能取地址、不能作为模板参数
std::is_constant_evaluated() 的常见误用陷阱
最常踩的坑是把它当成“当前是否在 consteval 函数里”，其实不是：consteval 函数内调用它一定返回 true，但 constexpr 函数在运行时被调用时，它就返回 false；反过来，普通函数即使被 constexpr 上下文调用（比如初始化 constexpr 变量），它也可能返回 true —— 关键看**实际执行路径是否被编译器选为常量求值**。
- 不能放在变量初始化器里直接用（如
constexpr bool b = std::is_constant_evaluated();）—— 编译失败，因为这不是常量表达式 - 不能在
if constexpr中用（if constexpr (std::is_constant_evaluated())）—— 语法错误，std::is_constant_evaluated()不是常量表达式上下文可接受的条件 - 在 lambda 内部调用时，行为取决于该 lambda 是否被用于常量求值（比如捕获了非字面量变量，就不可能进编译期路径）
一个实用示例：带 fallback 的编译期数组查找
下面这个函数在编译期尝试二分查找，运行期则线性扫描：
立即学习“C++免费学习笔记（深入）”；
constexpr int search_in_array(const int arr[], int size, int key) {
if (std::is_constant_evaluated()) {
// 编译期：可以安全递归、用复杂逻辑
for (int i = 0; i < size; ++i) {
if (arr[i] == key) return i;
}
return -1;
} else {
// 运行期：可调用 std::find、甚至 malloc（虽然这里没这么做）
for (int i = 0; i < size; ++i) {
if (arr[i] == key) return i;
}
return -1;
}
}
- 注意：这里用了简单循环而非真二分，是因为编译期对控制流深度有限制，太深可能触发 clang/gcc 的 constexpr stack overflow
- 数组必须是字面量或 constexpr 变量，否则
std::is_constant_evaluated()在该调用点仍可能返回false - 即使函数声明为
constexpr，若传入运行时变量（如int x; search_in_array(&x, 1, 5);），整个函数会退化为运行时执行，std::is_constant_evaluated()返回false
真正难的是让编译器“愿意”走常量求值路径——这取决于所有参数是否都能追溯到字面量或 constexpr 变量，而不仅是函数声明本身。一旦中间有运行时输入，std::is_constant_evaluated() 就只是个摆设。
