constexpr函数需满足编译期可求值约束，参数与返回类型须为字面类型，仅在常量表达式上下文中才强制编译期求值；consteval则严格限定只能编译期调用。
constexpr 函数必须满足编译期可求值的约束
不是所有函数加个 constexpr 就能进编译期——它本质是“编译器承诺能算出来”的契约。一旦函数体里出现运行时才确定的值（比如 std::cin、new、未初始化的局部变量），或者调用非 constexpr 函数，编译直接报错，典型错误是：error: call to non-constexpr function。
实操建议：
- 函数参数和返回类型必须是字面类型（
int、std::array、std::string_view等；std::string不行） - C++14 起允许函数体内有局部变量、循环、
if，但所有分支都得能静态判定（比如不能依赖argc） - 推荐用
static_assert验证：比如static_assert(my_func(5) == 25);，失败就立刻暴露问题
怎么让 constexpr 函数真正参与编译期计算？
加了 constexpr 不等于自动触发编译期求值——它只是“可以”，具体是否执行取决于使用上下文。只有当结果被用于需要常量表达式的地方，才会强制走编译期路径。
常见场景与判断依据：
立即学习“C++免费学习笔记（深入）”；
- 数组长度：
int arr[my_func(3)];→ 必须编译期算出 - 模板非类型参数：
std::array<int my_func> a;</int>→ 编译器会尝试求值 - 用在
static_assert或constexpr变量初始化中 - 但如果只是普通函数调用：
auto x = my_func(2);→ 默认按运行时处理（除非启用优化且内联成功）
constexpr 和 consteval 的关键区别在哪？
consteval（C++20 引入）是更严格的“纯编译期限定”：它声明的函数**只能**在编译期调用，任何运行时调用都会导致编译错误，比如 consteval int f() { return 42; } int x = f(); 在非 constexpr 上下文中调用，报错：error: call to consteval function 'f' is not a constant expression。
选哪个？
- 想兼容运行时和编译期 → 用
constexpr - 逻辑天然无法运行时（比如解析字面量字符串生成类型列表）→ 用
consteval，避免误用 - 注意：
consteval函数不能递归调用自身（编译器不展开无限递归），而constexpr在 C++20 后支持有限深度的编译期递归
容易被忽略的隐式转换陷阱
看似简单的 constexpr 函数，可能因隐式类型转换意外掉出常量表达式上下文。例如：
constexpr int to_int(char c) { return c - '0'; }
constexpr auto x = to_int('5'); // OK
constexpr auto y = to_int("5"[0]); // 错！"5"[0] 是 const char&，不是字面量，C++20 前不被视为常量表达式这类问题往往只在特定标准版本或编译器下暴露。实操要点：
- 优先用字面量或
constexpr变量传参，避免从非常量对象取值 - 对字符串字面量索引，C++20 起支持，但 GCC 12 之前可能不完全实现，需测试
- 用
std::is_constant_evaluated()（C++20）做运行时/编译期分支时，注意它本身不改变求值时机，只是提供判断依据
编译期优化不是加个关键字就自动生效的，它依赖整个调用链的“可推导性”——任何一个环节引入运行时依赖，整条链就退化。最常卡住的地方，其实是参数来源是否真的常量，而不是函数本身写得多漂亮。
