consteval：不是“更狠的 constexpr”，而是编译期求值的“硬性契约”

上周帮同事调一个模板元编程问题，他写了个 constexpr 函数，本意是让所有调用都在编译期完成，结果运行时还是生成了函数体——调试器一跟，发现某处调用传入的是运行时变量，编译器默默退化为普通函数调用。他挠头：“不是标了 constexpr 吗？怎么还能跑 runtime？”
这其实暴露了一个长期被模糊的认知：constexpr 是“可”在编译期求值，而 consteval 才是“必须”。它不提供备选路径，不妥协，不兜底——你给它运行时值，编译直接报错，连商量的余地都没有。

consteval 在 C++20 引入，表面看只是多了一个关键字，实际是编译期语义的一次“主权声明”。它把原本由程序员靠自觉和文档约定的“应该编译期计算”，变成了编译器强制执行的契约。

最直观的区别藏在错误信息里。
写一个 consteval int square(int x) { return x * x; }，然后在 main() 里写 int a = 5; auto s = square(a); —— 编译器不会生成代码，也不会警告，而是抛出类似 error: call to consteval function 'square' is not a constant expression 的硬性拒绝。这个错误无法绕过，也无法静默降级。它像一道闸门，只放行纯编译期上下文。

那什么算“纯编译期上下文”？简单说：所有输入必须是常量表达式（constant expression），且函数体内不能出现任何运行时不可判定的操作。比如 new、dynamic_cast、std::cout <<、甚至未初始化的局部变量定义都不行。但比 constexpr 更严的是：consteval 函数连 if constexpr 都不能依赖外部模板参数以外的条件分支——因为分支本身也必须在编译期完全确定。

实用场景往往出现在“零开销抽象”的关键节点。比如你要实现一个编译期字符串哈希，希望确保每次调用都彻底展开，不留 runtime 调用痕迹。用 constexpr 可能因调用链中混入运行时值而意外退化；用 consteval 就能一锤定音：

consteval uint32_t fnv1a_const(const char* s, size_t len, uint32_t hash = 0x811c9dc5) {
    return (len == 0) ? hash : 
           fnv1a_const(s + 1, len - 1, (hash ^ s[0]) * 0x1000193);
}

这个函数一旦被调用，就必须吃下字面量字符串或 std::string_view 的 constexpr 构造结果。你没法把它塞进一个 for 循环里动态调用——这恰恰是它的设计意图：把编译期计算从“能力”升级为“责任”。

有意思的是，consteval 和 constexpr 并非互斥。你可以给同一个函数同时加两个说明符：constexpr consteval 是非法的，但 consteval 函数天然满足 constexpr 要求，所以它自动是 constexpr 的超集。反过来，constexpr 函数却不能当 consteval 用——就像“会游泳”不等于“必须待在水里”。

一个容易被忽略的实战细节：consteval 函数的地址永远不可取。你不能写 auto ptr = □，因为它的存在仅限于编译期展开，没有 runtime 地址概念。这和 constexpr 函数不同——后者在需要时仍可生成 runtime 版本并取地址。这个限制不是缺陷，而是线索：它提醒你，consteval 的价值不在“复用”，而在“彻底消除”。

再进一步，consteval 让某些曾经棘手的问题变得干净利落。比如类型安全的枚举序列化：传统方案常靠宏或代码生成工具预埋字符串表，维护成本高。用 consteval，可以写一个在编译期遍历枚举值并生成静态映射表的函数——只要枚举值本身是 constexpr（它们本来就是），整个构建过程就锁死在编译期，无反射、无 RTTI、无运行时查找开销。

当然，它也有明确的边界。它不解决“如何让复杂逻辑变 constexpr”的问题——如果算法本身含运行时依赖（比如读文件、查系统时间），加 consteval 只会让编译失败得更快。它的作用对象，始终是那些逻辑上可静态判定、只是过去缺乏强制手段约束的场景。

回到开头那个调试故事。后来我们把几个关键计算函数标为 consteval，编译失败点立刻暴露了三处隐式运行时依赖——两处是忘了用 constexpr 构造 std::array，一处是误用了 std::vector。改完后，不仅性能提升可测，更重要的是：代码意图再也无法被无意绕过。

consteval 不是银弹，但它是一把刻着“此处禁止 runtime”的标尺。当你需要确保某段逻辑绝对不出现在最终二进制里，或者想提前捕获“本该编译期完成却意外滑向 runtime”的隐患时，它比任何注释、文档或 code review 都可靠。

毕竟，编译器从不撒谎，而 consteval，就是它说“不”的最笃定语气。