consteval 是 C++20 引入的强制编译期求值函数关键字，要求所有调用必须在编译期完成，否则直接报错；它不退化到运行时，仅接受常量表达式参数，用于确保零运行时代价的关键元编程场景。
consteval 是 C++20 引入的“强制编译期求值”函数关键字
它不是可选项，而是硬性要求：所有调用都必须在编译期完成，否则直接报错。和 constexpr 的“能编译期求值就编译期求值，不行就退化到运行时”完全不同——consteval 没有退路。
常见错误现象：consteval 函数传入变量（哪怕只是 int x = 5;）就会触发编译失败，错误信息通常是 call to consteval function 'xxx' is not a constant expression。
- 使用场景：需要绝对零运行时代价的元编程计算，比如生成固定大小的查找表、校验编译期配置合法性、构造类型级常量等
- 参数差异：只接受字面量、
constexpr变量、枚举值等能参与常量表达式的参数；不能接受任何运行时变量、std::string、堆分配对象 - 性能影响：无运行时开销，但会增加编译时间；若滥用复杂逻辑，可能显著拖慢构建
为什么不能用 constexpr 替代 consteval？
因为 constexpr 函数在运行时也能被调用——只要参数不是常量表达式，它就自动降级为普通函数。这在某些强约束场景下是危险的：你本想靠编译期检查确保某个值“永远不可变”，结果却在运行时悄悄执行了逻辑，还可能引入未定义行为或绕过安全校验。
例如，一个用于生成加密盐值长度的函数：
立即学习“C++免费学习笔记（深入）”；
constexpr int salt_length() { return 32; } // ✅ 合法，但……
如果后续有人误写成：
int len = get_user_config();<br>char buf[salt_length() + len]; // ❌ 编译通过！但语义已崩坏
而换成：
consteval int salt_length() { return 32; }<br>// int buf[salt_length() + len]; // ❌ 直接编译失败，守住边界
-
constexpr是“尽力而为”的优化提示，consteval是“必须满足”的契约 - 兼容性：C++20 起支持，老标准（C++17 及以前）完全不识别
consteval，需注意项目工具链版本 - 不能修饰变量或构造函数，仅限函数（包括 lambda 表达式中的
constevallambda）
consteval 和 constexpr 函数混用时要注意什么？
可以调用，但调用点必须仍是常量表达式上下文。比如一个 consteval 函数可以被另一个 constexpr 函数调用，前提是后者本身也在编译期被求值；但如果后者在运行时被调用，那里面再调 consteval 就会炸。
- 允许：
constexpr函数内部调用consteval函数，且该constexpr函数自身被用于常量表达式（如数组大小、模板参数） - 禁止：
constexpr函数在运行时被调用（比如参数是局部变量），此时其体内对consteval的调用会失败 - 调试线索：编译器通常不会告诉你“这里用了 consteval 导致失败”，而是报最外层调用点“not a constant expression”，得一层层往回查
consteval 不是万能的，别把它当 constexpr 加强版来用
它只解决一个问题：确保某段逻辑**绝不在运行时执行**。但它不提供额外的灵活性——比如不能捕获外部变量、不能抛异常（只能用 static_assert）、不能调用非 consteval/constexpr 函数（除非是标准库中明确标注的 constexpr 版本）。
容易踩的坑：
- 试图在
consteval函数里用std::vector或std::string—— 它们不支持编译期构造 - 循环次数依赖运行时输入（哪怕只是函数参数）—— 编译器无法验证迭代是否有限
- 忘了 C++20 中
consteval函数体仍受 constexpr 约束（比如不能有new、不能修改全局状态）
真正关键的分寸在于：你到底要的是“编译期可算”，还是“编译期必须算”。前者选 constexpr，后者才轮到 consteval。很多人一开始就想“越严格越好”，结果卡在编译器报错里反复挣扎，其实只是没想清楚这个前提。
