C++11起可用constexpr函数与模板递归实现编译期整数运算，需避免运行期习惯、确保所有分支静态可求值、手动处理除零；浮点运算推荐constexpr函数而非整型模板；向量矩阵宜用std::array配合constexpr构造；调试应拆分表达式并用static_assert验证类型与条件。
编译期整数运算：用 constexpr 和模板递归实现基础算术
直接结论：C++11 起就能靠 constexpr 函数 + 模板元编程实现编译期常量计算，不需要第三方库。关键不是“能不能”，而是“怎么写才不被编译器拒之门外”。
常见错误是把运行期习惯带进来——比如在 constexpr 函数里用 std::vector、循环变量未声明为 constexpr、或递归深度超限（GCC 默认 512 层，Clang 更严）。最稳妥的起点是纯整数、无状态、尾递归友好的运算。
-
constexpr函数必须所有分支都可静态求值；if要换成?:或特化模板 - 除法、模运算需手动处理除零——编译期除零会直接让
static_assert失败，而不是报错信息友好 - 推荐用模板参数而非函数参数传入常量，避免某些编译器对函数参数推导不充分（尤其 GCC 9 前）
例如阶乘：
template<int N> constexpr int factorial = (N <= 1) ? 1 : N * factorial<N-1>;
类型安全的编译期浮点运算：constexpr 函数比模板更实用
很多人试图用整型模板参数模拟浮点，结果陷入精度灾难和溢出。其实 C++14 起，constexpr 函数支持局部变量、for 循环、甚至 std::sqrt（只要输入是字面量），比整型模板更自然。
立即学习“C++免费学习笔记（深入）”；
但注意：浮点字面量参与编译期计算时，必须用 constexpr 变量绑定，否则可能被降级为运行期求值（尤其涉及 double 时）。
- 用
constexpr double x = 3.14159;而非直接写3.14159在表达式中 -
std::sin/std::cos等标准数学函数在 C++20 才保证constexpr，C++17 及以前只能依赖编译器扩展（如 GCC 的__builtin_sin） - 自己实现泰勒展开时，项数必须固定（比如展开到第 5 项），不能用
while动态控制——编译器无法验证循环终止
一个安全的平方根近似：
constexpr double sqrt_approx(double x) {
double r = x > 0 ? x : 1.0;
for (int i = 0; i < 5; ++i) r = (r + x / r) / 2;
return r;
}编译期向量/矩阵运算：用 std::array + constexpr 构造函数
别碰 std::vector——它没有 constexpr 构造函数。要用 std::array<T, N>，配合聚合初始化或自定义 constexpr 构造函数。
难点不在加减乘，而在索引合法性检查：编译期越界访问不会报错，而是导致 SFINAE 失败或静默截断。必须用 static_assert 显式约束维度。
- 矩阵乘法维度检查要放在函数签名层面（如模板参数
M,N,K），而不是函数体内 - 初始化列表长度必须与模板参数严格匹配，否则 GCC 报
not a constant expression - 避免在构造函数里做复杂逻辑；优先用
constexpr工厂函数返回std::array
示例（2×2 矩阵乘）：
template<typename T>
constexpr std::array<T, 4> matmul2x2(
const std::array<T, 4>& a,
const std::array<T, 4>& b) {
return {{
a[0]*b[0] + a[1]*b[2],
a[0]*b[1] + a[1]*b[3],
a[2]*b[0] + a[3]*b[2],
a[2]*b[1] + a[3]*b[3]
}};
}调试编译期计算失败：看错误位置比看错误信息更重要
编译器报错通常指向调用点，而非真正出问题的模板深处。真正有效的调试方式是逐步缩小范围：把嵌套表达式拆成中间 constexpr 变量，逐个验证。
常见陷阱是隐式类型转换——比如 int 除以 int 得 int，再转 double 就丢了精度，而这个过程在编译期无法触发警告。
- 用
static_assert(std::is_same_v<decltype(expr), expected_type>)检查中间类型 - 对模板参数加
static_assert(N > 0, "size must be positive")，比等报错后猜含义快得多 - Clang 错误信息比 GCC 更早暴露模板实例化栈，遇到卡顿时优先换 Clang 编译
最后提醒：编译期数学库的价值不在“炫技”，而在确保关键常量（如硬件寄存器偏移、协议字段长度）绝对不可能运行时出错。一旦涉及浮点精度或复杂控制流，就得权衡——有些事交给 constinit + 运行期初始化反而更清晰可靠。
