std::is_constant_evaluated()用于区分求值时机，使constexpr函数兼顾编译期与运行时逻辑；它不能替代consteval，不可在consteval函数中使用，且必须配合if constexpr或普通if，分支内代码须分别满足对应约束。
std::is_constant_evaluated() 不是用来“优化编译期分支”的——它本身不优化，而是让 consteval 函数或 constexpr 函数能**区分求值时机**，从而写出真正可复用的、兼顾编译期和运行时逻辑的代码。滥用或误以为它能自动触发常量折叠，反而会导致 ODR 违规、链接错误或编译失败。
为什么 std::is_constant_evaluated() 不能替代 consteval
很多人想用它“绕过 consteval 的纯编译期限制”，比如：
constexpr int f(int x) {
if (std::is_constant_evaluated()) {
return x * x; // ✅ 编译期可算
} else {
return expensive_runtime_calc(x); // ✅ 运行时可调
}
}
这看似灵活，但问题在于：std::is_constant_evaluated() 只在「当前求值上下文确定为常量求值时」才返回 true，而这个判断发生在**函数被调用的那一刻**，不是定义时。所以：
- 若你用
f(5)初始化constexpr int a = f(5);，它返回true，走编译期分支 - 但若你写
int b = f(some_runtime_var);，即使f内部有std::is_constant_evaluated()，它也返回false，走运行时分支 -
关键陷阱：如果函数里用了仅编译期可用的表达式（比如
std::array的size()、static_assert、或对未初始化constexpr变量取地址），却放在else分支里——编译器仍会尝试实例化整个函数体，导致编译失败，哪怕那部分根本不会执行
consteval 函数里调用 std::is_constant_evaluated() 是无效的
consteval 函数强制必须在编译期求值，因此其内部调用 std::is_constant_evaluated() 永远返回 true，毫无意义。更危险的是，有人试图这样写：
consteval int g(int x) {
if (std::is_constant_evaluated()) {
return x + 1;
} else {
return x - 1; // ❌ 永远不可达，且可能因含运行时语义（如 new、IO）直接报错
}
}
这不仅冗余，还容易引入不可达代码警告，甚至因 else 分支含非法 constexpr 表达式而编译失败。正确做法是：既然是 consteval，就只写纯编译期安全逻辑，别加运行时兜底。
真正推荐的配合方式：分离职责 + 显式重载
最可靠、最易维护的模式是：用 consteval 处理纯编译期路径，用普通 constexpr 或非 constexpr 函数处理运行时路径，并通过函数重载或模板特化明确分发。例如：
consteval int square_cx(int x) {
return x * x;
}
<p>constexpr int square(int x) {
if (std::is_constant_evaluated()) {
return square_cx(x); // ✅ 安全：只调用已知纯编译期函数
} else {
return x * x; // ✅ 运行时也够快，无副作用
}
}</p>
这样做的好处：
- 编译期路径由
consteval保证正确性，不污染运行时逻辑 -
std::is_constant_evaluated()只用于分发，不嵌入复杂计算，降低误用风险 - 避免在同一个函数体内混写编译期/运行时敏感操作（比如
std::vector构造、dynamic_cast） - 调试时更容易定位哪条路径实际被选中（加
static_assert或编译器内置宏辅助）
最容易被忽略的一点：当你把 std::is_constant_evaluated() 放进模板函数，且模板参数本身依赖运行时值（比如 std::size_t N 来自非 constexpr 变量），那么即使函数标了 constexpr，该调用点也无法进入编译期分支——std::is_constant_evaluated() 看的是“这次调用能否常量求值”，不是“函数能不能被常量化”。这点在泛型库中尤其容易踩坑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
