应使用 if consteval 语法，它是C++23新增的编译期/运行期硬分叉机制，必须位于constexpr或consteval函数内且强制配对else，语义明确、无误判风险。
怎么用 if consteval 判断当前是否在编译期执行
直接写 if consteval，不是 if constexpr，也不是 if (consteval) —— 后两者都错。if consteval 是 C++23 新增的专用语法，专为区分编译期/运行期分支设计。
它不依赖常量表达式推导，也不需要你手动写 std::is_constant_evaluated()，更不会被优化器“猜错”。只要进了这个 if 分支，就 100% 在编译期求值；进了 else，就 100% 是运行期。
-
if consteval只能出现在函数体内，且该函数必须是constexpr或consteval的 - 不能单独用，必须配对
else（C++23 要求），else if consteval不合法 - 分支内代码仍需满足各自上下文约束：编译期分支里不能调
std::printf，运行期分支里可以，但不能反着来
if consteval 和 std::is_constant_evaluated() 该怎么选
优先用 if consteval。它语义清晰、无误判风险、编译器能更好优化。而 std::is_constant_evaluated() 是 C++20 引入的“补丁”，靠运行时检测伪指令，实际在某些编译器（如早期 GCC 12）或特定优化级别下会返回错误结果。
-
if consteval是编译期硬分叉，分支逻辑完全隔离；std::is_constant_evaluated()返回bool，容易被条件折叠、内联或死代码消除干扰 - 如果要兼容 C++20，才退而用
std::is_constant_evaluated()；C++23 项目没理由绕开if consteval - 注意：
std::is_constant_evaluated()在consteval函数里恒返回true，但它本身不保证调用者是编译期调用——这点常被忽略
常见报错和编译失败原因
最典型的错误是把 if consteval 写在非 constexpr 函数里，或者漏写 else。Clang 会报 error: 'if consteval' must be used in a constexpr context，GCC 可能更模糊地提示 invalid use of 'consteval'。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 函数声明没加
constexpr（哪怕函数体里只用了if consteval）→ 编译失败 - 分支里用了运行期才合法的操作（比如
new、std::cout、未初始化的局部静态变量）→ 编译期分支报错 - 试图在
if consteval外部取地址或绑定引用到编译期分支里的局部变量 → 报错，因为那块内存根本不存在于运行期
一个实用的小例子：编译期查表 + 运行期 fallback
比如实现一个字符串哈希：小字符串走编译期计算（生成字面量哈希值），大字符串运行期算（避免模板爆胀）。
constexpr uint32_t hash(const char* s, size_t n) {
if consteval {
uint32_t h = 0;
for (size_t i = 0; i < n; ++i)
h = h * 31 + s[i];
return h;
} else {
// 运行期可做 memcpy、malloc、甚至调用 OpenSSL
return slow_hash_runtime(s, n);
}
}
关键点：这里 n 必须是编译期已知大小（比如传入 sizeof("abc")-1），否则 if consteval 分支进不去；而 slow_hash_runtime 完全不用管 constexpr 约束。
最容易被忽略的是：编译期分支的代码，哪怕逻辑上“看起来能运行”，也必须满足所有 constexpr 函数的限制——比如不能用虚函数、不能有未定义行为、不能越界读字符串字面量末尾。这些错误往往不报“consteval 失败”，而是直接让整个函数退出 constexpr 上下文，导致调用处编译失败。
