is_constant_evaluated() 仅在明确处于常量求值环境时返回 true，如 constexpr 函数被用于数组大小、模板参数或 consteval 函数中；普通调用即使函数为 constexpr 也返回 false。
is_constant_evaluated() 什么时候返回 true
is_constant_evaluated() 不是“编译期检测开关”，它只在当前求值环境明确属于常量求值（constant evaluation）时才返回 true。比如在 constexpr 函数体内、被用于需要常量表达式的地方（如数组大小、模板非类型参数），且实际调用发生在编译期上下文中——但它本身不强制编译期求值。
常见错误现象：constexpr int f() { return is_constant_evaluated() ? 42 : 0; }，然后写 int x = f(); —— 这里 f() 被当作普通函数调用，is_constant_evaluated() 返回 false，哪怕函数本身是 constexpr。
- 只有当调用点被要求是常量表达式时，才会触发常量求值路径（例如
constexpr int y = f();或int arr[f()] = {};） - 在
consteval函数中调用，is_constant_evaluated()总是true（因为只能编译期执行） - 在模板实例化中作为非类型模板参数推导时，也会进入常量求值路径
怎么安全地用 is_constant_evaluated() 做分支优化
它的典型用途是：同一份逻辑，在编译期走轻量路径（比如查表、硬编码），运行期走通用路径（比如调用 std::sqrt、分配内存）。但必须确保两个分支都合法 —— 编译期分支不能含运行期才允许的操作。
常见错误现象：在 true 分支里调用 new、std::printf、或对未初始化变量取地址，导致编译失败。
立即学习“C++免费学习笔记（深入）”；
- 编译期分支只能用字面量、
constexpr函数、constexpr变量、static_assert等 - 运行期分支可自由使用任何运行时设施，但不能反向污染编译期分支
- 推荐把两套逻辑拆成独立的
constexpr和非constexpr辅助函数，主函数只做跳转
示例：
constexpr int fast_pow(int base, int exp) {
if (is_constant_evaluated()) {
// 编译期：展开循环或递归
int r = 1;
for (int i = 0; i < exp; ++i) r *= base;
return r;
} else {
// 运行期：可用更优算法（如快速幂），甚至调用库函数
return std::pow(base, exp); // 注意：std::pow 非 constexpr，只能放这里
}
}
为什么 clang/gcc 行为有时不一致
是否进入常量求值路径，取决于编译器对调用点的语义判定，而不同版本对“隐式常量求值”的激进程度不同。比如某些 GCC 版本会在 constinit 变量初始化中更积极地尝试常量求值，而 Clang 可能更保守。
常见错误现象：代码在 GCC 上编译通过并返回 true，换 Clang 就报错“call to non-constexpr function”，或始终返回 false。
- 不要依赖未明确要求常量表达式的上下文（比如普通
const变量初始化） - 显式用
constexpr变量、模板参数、static_assert等锚定求值时机 - C++20 标准只要求“当且仅当求值必须是常量时”才返回
true，实现可自行决定何时尝试
替代方案比 is_constant_evaluated() 更稳吗
没有银弹。有人想用 if consteval（C++23）替代，但它本质是语法糖，底层仍依赖相同机制；也有人试图用模板特化 + std::is_constant_evaluated_v（不存在！），结果编译失败。
真正容易被忽略的点：你写的“编译期逻辑”可能根本没被调用——因为编译器内联/常量传播没触发，或者你误以为某个上下文是常量求值，其实不是。
-
if consteval更清晰，但仅限 C++23，且仍受同样语义约束 - 用
constexpr if+ 类型特征（如std::is_integral_v<t></t>）做编译期决策，和is_constant_evaluated()解决的是不同问题 - 最稳的做法：把必须编译期完成的部分，单独抽成独立
constexpr函数，并在明确要求常量表达式的地方调用它
事情说清了就结束
