二分递归将constexpr调用栈深度从O(n)降至O(log n)，避免编译器递归深度超限；安全幂函数需严格二分、无回退分支；模板参数包展开则彻底消除递归帧。
为什么二分递归能压低 constexpr 调用栈深度
编译器对 constexpr 函数的递归深度有硬性限制（如 GCC 默认 512 层），线性递归（比如 factorial(n-1) 或朴素幂运算）会把深度拉到 O(n)，n=1000 就直接报错 constexpr evaluation exceeded maximum depth。而二分递归把问题规模每次砍半，深度降为 O(log n)——1000 变成约 10 层，稳过限制。
关键不是“更快”，是“更浅”：编译期求值不关心运行时耗时，只卡调用帧数。每层递归都生成一个独立的 constexpr 帧，帧数超标就停编译。
怎么写一个安全的二分 constexpr 幂函数
必须避免线性展开分支，所有路径都要走二分逻辑，否则编译器可能退化回线性路径。下面这个写法是可靠的：
constexpr int power(int base, int exp) {
if (exp == 0) return 1;
if (exp == 1) return base;
const int half = power(base, exp / 2);
if (exp % 2 == 0) {
return half * half;
} else {
return half * half * base;
}
}
- 终止条件覆盖
exp == 0和exp == 1，不依赖exp - 1的链式递减 -
exp / 2确保每轮规模至少减半，exp为编译期常量时，除法结果也是常量 - 没有
power(base, exp - 1)这类线性回退分支，否则编译器可能对某些输入走深路径
模板参数包展开替代递归的适用边界
当你要生成固定长度的编译期数组（比如查表、位掩码、索引序列），用 std::index_sequence 展开比递归更彻底——它根本不产生递归调用帧，而是编译器在实例化时直接展开为一串并列表达式。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
例如生成 2 的前 16 次幂：
template <size_t... I>
constexpr auto build_powers(std::index_sequence<I...>) {
return std::array<int, sizeof...(I)>{(1 << I)...};
}
constexpr auto powers = build_powers(std::make_index_sequence<16>{});
- 适用于长度已知且不太大（
sizeof...(I) ）的场景；超长会触发模板实例化深度限制，但那是另一套机制（<code>-ftemplate-depth=） - 不能用于依赖运行时输入的动态长度，因为
std::index_sequence必须是编译期常量 - 零运行时开销，数组内容完全在编译期确定，比任何 constexpr 递归都干净
容易被忽略的陷阱：constexpr 里混用非字面量类型或副作用
即使你把递归改成二分，只要函数体里出现以下任一情况，整个函数就不再是 constexpr，编译器会静默降级为运行时调用——此时深度限制不生效，但你也失去了编译期计算的意义：
- 调用非
constexpr函数（比如std::sqrt、printf） - 使用
static变量、new、try/catch - 返回或操作非字面量类型（如
std::string、未标记constexpr构造函数的类） - 哪怕只有一行
int x = 42;没加constexpr修饰，在 C++17 前也可能破坏常量性
真正卡住人的，往往不是递归太深，而是某处悄悄破坏了 constexpr 合法性，导致你以为在编译期算，其实拖到了运行时。先确认函数确实被当作常量表达式使用（比如用它初始化 constexpr int x = power(2, 10);），再调深度参数。
