std::is_constant_evaluated()是唯一能在constexpr函数中安全分流编译期与运行时逻辑的标准工具；它在编译期求值时返回true、运行时调用时返回false，且自身为constexpr，而其他条件分支因需全路径合规而不可行。
在 constexpr 函数里调用运行时才高效的逻辑（比如查表、递归展开、字符串解析），std::is_constant_evaluated() 是唯一能安全分流的工具——不用它，编译期求值可能卡死或爆内存，运行时调用又白丢优化机会。
为什么不能直接写 if (true) { 编译期路径 } else { 运行时路径 }
因为 constexpr 函数体内所有分支都必须在编译期可验证合法。哪怕你用 if (false) 包裹一段含 new 或 I/O 的代码，编译器仍会尝试检查其是否满足 constexpr 约束，直接报错：error: call to non-constexpr function。这不是“跳过”，是“不允许存在”。std::is_constant_evaluated() 是唯一被标准特许的、能在 constexpr 上下文中做语义分流的函数——它本身是 constexpr，且在编译期求值时返回 true，运行期调用时返回 false。
典型误用：把 is_constant_evaluated() 当作编译期检测宏
它不反映当前是否在 constexpr 函数里，而是反映**本次调用是否正在为常量表达式求值**。常见坑点：
- 在非 constexpr 函数中调用它，永远返回
false（哪怕函数内嵌套 constexpr 调用） - 在 constexpr 函数中，若参数含非常量值（如局部变量、函数参数未标记
consteval），即使函数声明为constexpr，该次调用仍按运行时处理，std::is_constant_evaluated()返回false - 不要把它和
__builtin_is_constant_evaluated()混用——后者是 GCC/Clang 扩展，行为不完全一致，且非标准
正确分流模式：查表 vs 计算
以计算 Fibonacci 为例：编译期适合小值查表（避免模板递归爆炸），运行期适合迭代（避免栈溢出）。关键不是“能不能算”，而是“值从哪来”：
constexpr int fib(int n) {
if (n
<p>注意：<code>std::is_constant_evaluated()</code> 必须出现在函数体最外层判断中；不能包在 lambda 里，也不能依赖其返回值做模板参数推导（它不是常量表达式）。</p>
<h3>兼容性与替代方案的现实约束</h3>
<p>C++20 引入，但 MSVC 19.26+、GCC 10+、Clang 11+ 才稳定支持。旧项目若需兼容：</p>
- 不要试图用宏模拟——没有预处理器能感知求值阶段
- 对 C++17 项目，只能拆成两个函数：
constexpr_fib()和runtime_fib()，由调用方显式选择 - 某些场景可用
consteval强制编译期执行，但它无法共存运行时路径，本质是“二选一”而非“自动分流”
真正难的不是写对这个函数，而是想清楚：哪些逻辑在编译期值得做、做到多深；哪些必须让步给运行时的确定性。一旦分支里混进未加保护的 std::vector 构造或动态分配，整个 constexpr 路径就废了——而这种错误，编译器不会提醒你，只会静默降级为运行时调用，然后性能陷阱照旧。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
