constexpr函数可执行复杂计算，只要输入编译期已知且无运行时行为；C++17支持循环与条件，C++20扩展至try和部分容器；需所有调用函数为constexpr、参数为字面类型且为编译期常量。
constexpr 函数能做多复杂的计算？
只要所有输入在编译期可知、所有操作不触发运行时行为（比如动态内存分配、I/O、虚函数调用），constexpr 函数就能在编译期求值。C++17 起支持 if、for、while，C++20 还允许 try、dynamic_cast（受限）、甚至部分容器（如 std::array）——但别指望 std::vector 或 new。
常见错误现象：error: call to non-constexpr function，往往因为用了未标记 constexpr 的辅助函数，或传入了非常量表达式（比如普通局部变量、未加 constexpr 修饰的全局变量）。
- 确保所有被调用的函数都声明为
constexpr（包括标准库中明确标注的，如std::min、std::pow（C++26 起）） - 输入参数必须是字面类型（
literal type），且实际调用时提供编译期常量（如42、constexpr int x = 5;） - C++17 起函数体默认是
constexpr的（只要满足约束），但显式写上更清晰、也兼容旧标准
递归深度与编译器限制怎么绕？
编译期递归不是运行时递归，它靠模板实例化或 constexpr 展开，但编译器会设上限（GCC 默认 512，Clang 约 256）。超限报错通常是：error: constexpr evaluation hit maximum step limit 或模板实例化深度超限。
- 优先用循环代替递归：C++17+ 的
constexpr函数支持for，比递归更可控、更易读 - 对数级展开：比如幂运算用快速幂（
pow(n, k)拆成k的二进制位），把 O(k) 降到 O(log k) - 用
std::array预存小范围结果（如阶乘前 20 项），查表比算快，也规避深度问题
示例：编译期计算斐波那契第 n 项（非递归版）：
立即学习“C++免费学习笔记（深入）”；
constexpr long long fib(int n) {
if (n <= 1) return n;
long long a = 0, b = 1;
for (int i = 2; i <= n; ++i) {
long long c = a + b;
a = b;
b = c;
}
return b;
}
constexpr 变量 vs constexpr 函数：什么时候该用哪个？
constexpr 变量是“结果”，constexpr 函数是“能力”。变量一旦定义就必须有确定值；函数则延迟求值，只在需要时触发编译期计算。
- 用
constexpr变量：当值固定、简洁、复用频繁（如constexpr auto PI = 3.14159265358979323846;） - 用
constexpr函数：当输入可变、逻辑复杂、或需适配不同模板参数（比如根据N生成长度为N的std::array） - 注意：函数返回
constexpr类型不等于函数本身是constexpr——必须显式声明函数为constexpr
典型误用：constexpr auto x = some_func(y); 中 y 不是常量表达式 → 编译失败，而非静默降级为运行时调用。
编译期字符串处理为什么容易翻车？
C++20 引入 std::string_view 和 consteval 后，编译期字符串操作才真正可行，但坑依然密集。
- 不能用 C 风格字符串字面量直接构造可变对象（
"abc"是const char[4]，不是std::string） - 所有字符串操作必须基于字面量或
constexpr构造的std::array<char n></char>，且长度必须在编译期确定 - 正则匹配、大小写转换这类看似简单的事，在编译期做要手写状态机或查表，性能不差，但开发成本高
一个安全起点：constexpr std::string_view 可以传入 constexpr 函数，用于解析固定格式（如版本号 "v1.2.3" 提取主版本），但别试图在编译期做 UTF-8 解码。
最常被忽略的一点：编译期计算不是银弹。过度使用会让编译时间飙升，尤其是嵌套模板 + constexpr 组合；调试困难（错误信息晦涩）；跨编译器行为可能不一致（比如对“足够简单”的判断）。真要压榨性能，先确认这一步是瓶颈，再动手。
