consteval函数必须且只能在编译期求值，任何运行时调用或非常量参数均导致编译失败；其参数须为字面类型且实参为常量表达式，函数体内禁止运行时行为、this指针及非consteval/constexpr调用。
consteval 函数必须完全在编译期求值，否则直接编译失败
它不是“尽量优化”，而是强制约束：只要调用场景无法在编译期确定所有输入（比如参数来自 main 中的局部变量），编译器立刻报错，不给运行时退路。consteval 函数体内也不能出现任何运行时才可决定的行为——比如读文件、调用非 consteval/constexpr 非内联函数、使用 new、抛异常（除非是编译期可捕获的 std::integral_constant 类型）。
常见错误现象：error: call to consteval function 'xxx' is not a constant expression。这通常是因为你传入了非常量表达式，比如 int x = 5; foo(x);，哪怕 x 看起来是字面量，但它的类型不是字面类型或未被声明为 constexpr。
- 所有参数类型必须是字面类型（
int、std::string_view、std::array等），且实参本身得是常量表达式 - 函数体里不能有
static变量、try/catch（除非 catch 的是编译期可判定的类型）、asm块 - 调用链上所有被调用函数也必须是
consteval或constexpr（且实际能被编译期求值）
和 constexpr 函数的关键区别在于“是否允许运行时调用”
constexpr 是“可编译期求值”，consteval 是“只能编译期求值”。一个 constexpr 函数可以既用于 static_assert，也能在运行时被普通调用；而 consteval 函数一旦出现在运行时上下文（比如作为 auto x = f(y); 中的 f，且 y 非常量），编译直接终止。
使用场景很具体：生成类型名字符串、计算模板参数边界、构建编译期查找表、校验配置字面量合法性（如确保端口号在 1–65535）。它不适合做“可能运行时用到”的通用逻辑。
立即学习“C++免费学习笔记（深入）”；
- 想写个编译期哈希？用
consteval，因为你不希望它在运行时再算一遍 - 想写个既能编译期又能运行时用的数学工具？选
constexpr，别硬套consteval - 性能影响：二者生成的机器码一样（零开销），但
consteval会让编译变慢——编译器必须对每个调用点做完整常量折叠验证
consteval 函数内部不能依赖运行时状态，包括 this 指针
即使你把它定义在类里，consteval 成员函数也不能访问 this（除非是字面类型的静态成员），因为 this 在运行时才有意义。换句话说：它不能是“某个对象的方法”，只能是“纯逻辑转换”。
典型误用：struct Config { int port; consteval int get_port() const { return port; } }; —— 这会失败，因为 port 是实例成员，其值不随对象存在而成为常量表达式。
- 正确做法：把数据以模板参数或
constexpr变量形式传入，例如template<int port> consteval int validate_port() { ... }</int> - 如果需要封装，用
constexpr构造函数 +consteval静态成员函数组合，比如static consteval auto make() { return Type{...}; } - 注意
std::string_view可以安全传入，但它的底层指针必须指向编译期已知内存（如字符串字面量），不能是std::vector<char></char>的 data()
调试 consteval 函数最有效的方式是看编译器报错位置和 SFINAE 上下文
它不像运行时函数那样能打日志或断点。出错时，错误信息往往嵌套很深，尤其在模板实例化中。GCC/Clang 会指出“here is the first non-constant subexpression”，但这个“here”可能是某层间接调用的参数传递点，而非你写的函数体第一行。
容易踩的坑是过度信任 IDE 提示——很多编辑器对 consteval 支持滞后，显示“无错误”，结果一编译就崩。真正可靠的验证只有实际编译 + static_assert。
- 写完立刻加一句
static_assert(my_func(42) == 1729);，这是黄金验证手段 - 避免在复杂模板元函数中直接嵌套调用，先抽成独立
consteval函数，降低错误定位难度 - Clang 15+ 和 GCC 13+ 对
consteval错误提示更友好，旧版本可能只报“not a constant expression”却不指明哪一步破环了常量性
最麻烦的从来不是语法写不对，而是你以为某个值是常量，其实它只是“看起来像”——比如从 std::array 的 operator[] 取出来的元素，在 C++20 前不是常量表达式，C++20 起才是。这种隐含依赖，得一行行查标准或用 static_assert(std::is_constant_evaluated()) 辅助判断。
