consteval，在 C++20 中引入，指定 立即函数 必须生成编译时常量。与 constexpr 不同，constexpr 允许在参数不是常量表达式时进行运行时执行，而 consteval 强制要求每个调用在常量计算上下文中进行。这种强制执行将潜在的运行时逻辑转化为严格的编译时要求，将静默的运行时回退机制转换为立即的编译失败。
从历史上看，constexpr 的双重性质导致开发人员假设零成本的编译时评估，但无意中触发了运行时代码生成。consteval 消除了这种模糊性，完全消除了运行时路径，确保违规情况表现为格式错误的程序，而不是性能回归或安全漏洞。
一个嵌入式系统团队需要保证加密种子值完全在编译时计算，以防止固件图像中的篡改。他们最初使用 constexpr 哈希函数，以为编译器会在构建过程中评估所有调用。
解决方案 1：静态断言保护
工程师将每个哈希调用包裹在 static_assert 中，认为这会阻止运行时评估尝试。尽管这种方法在单元测试中有效，但在集成过程中却失败，因为另一位开发人员将运行时配置标志传递给哈希函数。编译器静默生成了哈希算法的机器代码，导致二进制大小膨胀了十二千字节，并违反了实时约束。静态断言只验证特定调用位置，而不是所有潜在调用。
解决方案 2：模板元编程 他们考虑使用 结构 特化和递归编译时递归将算法转换为 模板 元编程。这种方法保证了编译时评估，但产生了五百多行的难以理解的错误消息，因小的类型不匹配而显得极为复杂。调试变得不可承受的困难，并且由于过度的 模板 实例化深度，编译时间增加了四百个百分点。
解决方案 3：consteval 强制（选择） 将函数迁移到 consteval 提供了立即的诊断，当开发人员试图进行运行时调用时。编译器将任何非常量参数视为严重错误，防止该函数生成任何运行时指令。该团队选择了这个解决方案，因为它保持了可读的语法，同时提供了关于执行时机的绝对保证，而没有 模板 膨胀。
结果完全消除了运行时种子生成的风险。二进制大小回到预期范围，构建系统在几秒钟内捕获配置错误，而不是在晚期集成测试期间。
为何 consteval 函数可以调用 constexpr 函数，但反向调用则需要严格的上下文约束？
consteval 函数仅在常量计算上下文中运行，因此调用 constexpr 函数总是安全的，因为编译时合同被保存。然而，constexpr 函数可以在运行时执行，这意味着它不能调用 consteval 函数，除非该特定调用位置本身显然是常量计算。尝试从 constexpr 函数的运行时分支调用 consteval 将导致格式错误的程序，因为 consteval 要求立即评估，运行时上下文无法满足这一要求。
为何获取 consteval 函数的地址会违反语言规范？
consteval 函数没有运行时地址或可调用主体；它们纯粹作为编译时计算原语存在。因此，表达式 &func 是格式错误的，因为没有内存位置可以引用。相比之下，constexpr 函数具有编译时计算器和运行时可执行代码的双重身份，允许其地址被获取并存储在函数指针或 std::function 对象中。
如何 consteval 与 constexpr 不同地处理未定义行为，这对安全关键代码有何影响？
在 consteval 函数内，任何未定义行为在编译期间使程序立即格式错误，防止生成易受攻击的运行时机器代码。constexpr 评估在常量折叠过程中检测某些未定义行为，但允许代码在运行时以未定义语义执行。consteval 的严格模型确保验证过的代码路径不受未定义行为漏洞的影响，从而实现激进的编译器优化，并确保安全敏感的计算在生产环境中不会遇到缓冲区溢出或整数溢出问题。