constexpr函数可在编译期计算斐波那契，比模板递归更简洁安全；需确保参数为常量表达式、所有分支可编译期求值，注意递归深度限制，推荐尾递归或迭代写法。
编译期计算斐波那契：用 constexpr 函数最直接
C++11 起，constexpr 函数就能在编译期算斐波那契，比模板递归更简洁、可读性更好，也避免模板深度爆炸。只要参数是常量表达式，调用就发生在编译期。
常见错误是写成非 constexpr 递归函数，或用了运行时才确定的变量（比如 int n = 5; 再传入），导致退化为运行时计算。
-
constexpr函数必须所有分支都可被编译期求值；递归深度受编译器限制（GCC/Clang 默认约 512 层，可通过-fconstexpr-depth=调整） - 推荐用尾递归风格或迭代写法，避免栈式递归带来的深度压力
- 示例：
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; } static_assert(fib(10) == 55, "compile-time check");
传统模板元编程实现：用 struct 偏特化递归
这是 C++98/03 时代的经典做法，现在仍见于需要兼容旧标准或深度元编程组合的场景。核心是定义主模板和两个偏特化：n == 0 和 n == 1，其余靠递归继承或静态成员。
容易踩的坑是忘记终止特化，或把 enum 改成 static constexpr int 后没加 inline（C++17 前需定义外置），导致链接错误。
立即学习“C++免费学习笔记（深入）”；
- 模板参数必须是字面类型（
int、size_t等），不能是浮点或自定义类 - 递归实例化深度由
template-recursion-depth控制，超限报错类似：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<12>::value == 144, "");
为什么不用 std::integer_sequence？它不适用于斐波那契计算
std::integer_sequence 是生成整数列表的工具，适合展开参数包或索引映射，但它本身不提供计算能力。有人误以为“序列”能推导数值，其实它只负责构造 0,1,...,N-1 这类等差序列，无法表达斐波那契的非线性递推关系。
强行套用会导致代码绕弯：先生成长度为 N 的序列，再用折叠表达式或辅助模板逐项计算——最终还是回到 constexpr 或模板递归的老路，且更难调试。
- 它的典型用途是配合
std::make_index_sequence实现完美转发、结构体绑定等，不是数值计算接口 - 若你看到用
integer_sequence“算斐波那契”的例子，大概率是混淆了“生成索引”和“执行递推”两个阶段
编译期结果怎么用：别忘了 constexpr 变量和模板参数
算出来的值要真正参与编译期决策，得让它成为常量表达式上下文的一部分。常见误操作是把它赋给普通变量，或者试图用在非 constexpr 上下文中（如普通数组大小但未声明为 constexpr）。
关键点在于：值本身是否被编译器认定为“已知”，取决于它如何被声明和使用。
- 正确用法：
constexpr int f10 = fib::value;或char buf[fib::value];（C++14 起支持非字面类型作为数组大小） - 错误用法：
int x = fib::value;—— 此时x是运行时变量，即使右边是编译期常量 - 模板参数场景中，必须确保推导出的值是字面常量：例如
template<int n> void foo() { ... }</int>，调用foo<fib>::value>()</fib>是合法的
模板元编程的“元”字容易让人高估复杂度；实际上对斐波那契这种单变量递推，constexpr 函数已足够可靠。真正棘手的是多参数依赖、类型计算或需要 SFINAE 的场景——那些地方才真正需要模板的全部威力。
