constexpr函数仅在输入为常量表达式时保证编译期求值，否则退化为运行时执行；需满足字面值类型、无副作用语句、无非constexpr调用等约束，且c++标准版本差异显著影响兼容性。
constexpr 函数必须满足编译期可求值的约束
不是所有函数加个 constexpr 就能进编译期——它本质是“编译器承诺：这个函数在满足输入为常量表达式时，一定能在编译期算出结果”。一旦函数体里出现 new、static_cast（非平凡转换）、dynamic_cast、try、asm，或调用了非 constexpr 函数，整个函数就退化为普通函数，只在运行时执行。
常见错误现象：constexpr int f() { return std::rand(); } 编译失败；constexpr int g() { int x = 42; return x * 2; } 在 C++11 中非法（C++14 起允许局部变量），但若变量未被初始化为字面值类型常量，仍无法用于模板实参。
- 确保所有参数类型是字面值类型（
int、double、std::array、用户定义的带constexpr构造函数的类等） - 函数体只能包含单条
return表达式（C++11），或有限的语句（C++14+），且不能有未定义行为 - 递归深度受编译器限制（如 GCC 默认 512 层），过深会报错
error: constexpr evaluation depth exceeds maximum
用 constexpr 函数做模板实参或数组长度时，输入必须是常量表达式
这是最容易踩坑的地方：你以为传了个“看起来是常量”的值，结果编译不过。比如 int n = 5; constexpr auto arr = std::array<int f>{};</int> 会失败，因为 n 是运行时变量，哪怕值是 5，也不是常量表达式。
使用场景典型包括：作为模板非类型参数、定义栈上数组大小、初始化 std::array 长度、驱动 if constexpr 分支。
立即学习“C++免费学习笔记（深入）”；
- 合法输入只能是字面值（
42、'a'）、constexpr变量（constexpr int x = 10;）、枚举值、或其它constexpr函数的返回值（且其输入也满足条件） -
const不等于constexpr：const int y = some_runtime_func();即使值不变，也不能用于模板参数 - C++20 引入
consteval可强制函数**只能**在编译期求值，适合对安全性要求高的场景（如密码学常量生成）
constexpr 函数在 C++11/C++14/C++20 的行为差异影响兼容性
同一段代码，在不同标准下可能编译失败或行为不同。比如 C++11 要求 constexpr 函数必须是“纯表达式”，而 C++14 放宽到支持局部变量、循环、条件分支，C++20 更进一步支持 try 块（仅限于编译期路径）和更灵活的内存模型。
性能影响不大，但兼容性风险高：你写的 C++20 constexpr 函数在 C++17 工程里直接编译不过。
- 跨项目协作前先确认目标标准；CI 中建议用
-std=c++17显式指定，避免依赖编译器默认 - 避免在 C++11 兼容代码中使用
for循环或if语句——改用递归或三目运算符 - 注意
std::string_view在 C++17 才成为字面值类型，此前无法作为constexpr函数参数
调试 constexpr 计算失败：看错误位置比看错误信息更有用
编译器报错往往不直接说“这里不能 constexpr”，而是卡在下游使用处，比如 error: non-type template argument is not a constant expression。真正问题可能在上游某个函数调用里悄悄用了 std::sqrt（非 constexpr）或读了全局 const 变量。
实际排查建议：
- 从报错行向上逐层检查每个函数调用是否标了
constexpr，且其所有参数是否都满足常量表达式要求 - 把疑似有问题的子表达式单独提成
constexpr变量，让编译器提前报错（如constexpr auto tmp = helper(x);） - GCC/Clang 的
-fconstexpr-backtrace-limit=0可展开完整求值链，但输出冗长，优先用缩小范围法
编译期计算不是“越用越好”——过度嵌套或复杂逻辑会让编译变慢、错误信息难读，而且一旦某处不满足条件，整条链就掉回运行时。关键在于明确哪些值**必须**在编译期确定，而不是把所有数学运算都塞进 constexpr。
