constexpr比模板递归更推荐，因其更清晰安全、支持运行时回退、避免编译器递归深度限制且不占用模板实例化资源；但需在常量表达式上下文中调用才能真正编译期求值。
为什么 constexpr 比模板递归更推荐
编译期计算斐波那契，最直接想到的是模板元编程（TMP）递归，比如用 template<int N> struct fib。但 C++11 起，constexpr 函数已能更清晰、更安全地完成相同任务，且支持运行时回退。模板递归在 N 较大时容易触发编译器递归深度限制（如 GCC 默认 900 层），而 constexpr 函数由编译器自动优化为常量表达式，不占模板实例化资源。
实际项目中，除非你明确需要 C++11 之前兼容，或必须嵌入类型系统（比如生成不同长度的数组类型），否则优先写 constexpr 版本。
constexpr 斐波那契函数怎么写才真正编译期求值
关键不是加了 constexpr 就一定在编译期算——它只是“允许”编译期求值，最终是否发生，取决于调用上下文是否为常量表达式。下面是最小可靠写法：
constexpr int fib(int n) {
if (n <= 1) return n;
return fib(n-1) + fib(n-2);
}
使用时必须确保参数是字面量或 constexpr 变量：
立即学习“C++免费学习笔记（深入）”；
-
constexpr int x = fib(20);→ ✅ 编译期计算 -
const int y = fib(20);→ ❌ 运行时调用（C++14 起仍可能被优化，但不保证） -
int z = fib(20);→ ❌ 必然运行时
注意：C++14 起 constexpr 函数支持更多语句（如循环、局部变量），可改写为迭代版避免栈展开深度问题：
constexpr int fib(int n) {
if (n <= 1) return n;
int a = 0, b = 1;
for (int i = 2; i <= n; ++i) {
int c = a + b;
a = b;
b = c;
}
return b;
}
硬要用模板递归？这些坑躲不开
如果坚持用传统模板方式（例如为了教学或遗留系统），必须处理三个现实问题：
-
fib<0>和fib<1>必须特化，否则递归无终止条件，编译失败 - 默认情况下，
fib<N>的值需通过::value访问，不能直接当整型字面量用（C++17 起可用inline constexpr静态成员变量缓解） - GCC/Clang 对模板递归深度有限制，
fib<100>很可能报错error: template instantiation depth exceeds maximum of 900
一个最小可行模板定义：
template<int N>
struct fib {
static constexpr int value = fib<N-1>::value + fib<N-2>::value;
};
template<>
struct fib<0> { static constexpr int value = 0; };
template<>
struct fib<1> { static constexpr int value = 1; };
使用：static_assert(fib<10>::value == 55, "");
编译期结果怎么验证没掉到运行时
最可靠的方式是把它塞进需要常量表达式的地方，编译器会强制检查：
- 作为数组大小：
int arr[fib<15>::value];或int arr[fib(15)];（C++14+） - 用于
static_assert条件 - 初始化
constexpr变量
如果编译通过且没警告，基本可确认是编译期求值。若想进一步确认，可查看编译器生成的汇编（如 g++ -S），fib(20) 应该直接展开为数字 6765，不会出现循环或函数调用指令。
别忽略一点：不同编译器对 constexpr 递归深度和复杂度的容忍度不同，尤其涉及大数时，建议在目标工具链上实测 fib(40) 是否仍能通过 static_assert。
