最近折腾了一个挺“行为艺术”的实验：用 C++ 模板元编程，把机器学习里的线性回归训练过程，整个搬到了编译期。也就是说，程序一旦编译成功，模型就已经训练完了，运行时没有任何训练代码，只留结果。听起来像考古级的模板技法配上了现代 ML，但实测下来，这套思路在嵌入式、固件、无 OS 环境这类“算力抠门”的场景里，还真有实用价值。这篇文章就把我的完整思路、关键实现和踩过的坑都记录下来，给同样对编译期计算和机器学习交叉感兴趣的读者一份能直接参考的笔记。
项目涉及的核心词就是“模板”“编译期”“机器学习”，核心玩法是用 C++ 模板递归加 constexpr 函数，在编译器完成模型推理甚至模型训练。适合谁看？如果你对 C++ 模板元编程感兴趣，又恰好接触过一点机器学习，想看看这两个领域的交汇点能长出什么；或者你是嵌入式开发者，想在不加任何运行时依赖的情况下塞一个极小模型进设备，这篇文章应该能给你不少启发。
1. 别被名字唬住：这个项目到底在解决什么问题
1.1 编译期计算的老底子
C++ 的模板元编程（Template Metaprogramming）其实早就是“编译期计算”的代名词了。模板在实例化时，编译器会根据模板参数展开代码，这个展开过程本身就是图灵完备的。上世纪九十年代末，大家就开始用模板递归算阶乘、算斐波那契数列，甚至用模板写编译期类型列表。那个年代的经典阶乘大概长这样：
template <std::size_t N> struct Factorial { static constexpr std::size_t value = N * Factorial<N - 1>::value; }; template <> struct Factorial<0> { static constexpr std::size_t value = 1; }; static_assert(Factorial<5>::value == 120, "5! should be 120");这段代码的意思是：编译器遇到Factorial<5>时，会往下递归实例化Factorial<4>、Factorial<3>……直到Factorial<0>这个特化作为递归出口。整个过程发生在编译阶段，程序运行起来后有的只是一个常量120。
后来 C++11 引入了constexpr，C++14 进一步放了权限，constexpr函数里可以写循环、局部变量和if，这让编译期计算从“类型特化艺术”变成了“更像普通代码的编程”。到了 C++17，标准库容器里有相当一部分接口也被标记为constexpr，比如std::array的operator[]。再加上std::pair也能在常量表达式里使用，这就意味着我们可以在编译期摆弄一小块数据、做数学计算、迭代训练模型，最后把训练结果变成常量。
1.2 为什么有人会把机器学习搬进编译期
有人可能会问：图什么呢？机器学习训练一般都在 Python、GPU、大数据集上跑，往编译器里塞，听着就像在拿指甲刀伐木。
但反过来想，有几个真实场景确实需要“极端压缩”：
- 零运行时开销。模型训练代码完全不进入二进制，运行时只有几个常量和几条乘加指令。对 MCU、嵌入式 RTOS、FPGA 软核这类资源紧张的环境来说，省下来的不只是 CPU，还有 ROM/RAM 空间。
- 编译期验收。如果训练到一半模型质量不合格，编译器直接报错，构建流程当场失败。这相当于把模型评估前移到构建阶段，比任何 CI 里跑测试都更前置。
- 模型参数不可篡改。编译期生成的参数是二进制里的常量，不存在“加载权重文件被篡改”的问题。对一些安全敏感的小型设备，这个特性很舒服。
我举个实际例子。之前我做过一个简单的传感器校准项目，设备每次开机要用一组线性系数把 ADC 原始值换算成物理量。传统做法是出厂前在电脑上跑一遍线性回归，得到系数后烧进配置区。但如果把训练放到编译期，你只需要把几组标准测量值写死在源代码里，编译时模型自己就把系数练出来了，设备端连配方文件都不用管。
1.3 这个项目的边界与价值
必须说清楚，编译期机器学习不是拿来替代 PyTorch、TensorFlow 的。它的适用面很窄：小规模样本、低维特征、简单模型。我实测下来，线性回归、感知机、K 近邻（KNN）、小型决策树这类模型都能在编译期跑通；但深层神经网络、百万级样本这种需求，编译器别说算不完，光是递归展开和常量求值步数就能把编译进程拖崩。
但这不代表这件事没价值。编译期机器学习最大的意义在于：它逼你把手里的模型拆到最底层，搞清楚前向传播每一步在做什么、梯度到底怎么算、学习率对收敛有多大影响。Python 里调sklearn的LinearRegression()一分钟出结果，可你要把它写进模板里，就必须把每个数学步骤落到可见的代码层面，这个过程对理解机器学习本质的帮助，比跑一百个现成 demo 都大。
2. 支撑编译期机器学习的关键机制
2.1 constexpr：C++ 给编译器的“运行通道”
constexpr是编译期机器学习的基座。它的意思是“这个表达式可以在编译期求值”，但注意，不是“必须在编译期求值”。一个constexpr函数既能用来给static_assert提供常量，也能在运行期被普通代码调用，具体取决于使用上下文。
C++ 各个版本对constexpr的放开速度是这样的：
| 版本 | constexpr 能力 |
|---|---|
| C++11 | 只能写单一return表达式，不能用循环、不能改局部变量，实用性有限 |
| C++14 | 放开循环、局部变量、if，constexpr 函数已经接近普通函数 |
| C++17 | std::array的operator[]、begin/end等大量算法变为 constexpr，if constexpr也来了 |
| C++20 | 放宽更多，支持 constexpr 的std::vector、std::string（部分实现）、consteval强制编译期求值 |
我用的基线是 C++17。因为要让训练函数拿到编译期数据，std::array是非常重要的容器，而它的operator[]在 C++17 才是 constexpr。如果你手头只有 C++14，也不是不能做，但std::array的大部分操作在常量表达式里会直接报错，得自己造轮子，麻烦不少。
2.2 模板：把数据和超参数写进类型
模板在编译期机器学习里承担的是“参数与类型环境”的角色。我们会把训练数据集的长度、迭代次数、数据类型这些信息直接放在模板参数里。比如：
template <typename T, std::size_t N, std::size_t Iterations> constexpr std::pair<T, T> train_linear_model( const std::array<std::pair<T, T>, N>& data, T learning_rate);T是浮点类型，N是样本数量，Iterations是训练迭代次数。这三个参数在编译期就被固定下来，编译器为每一种模板参数组合生成独立的代码。也就是说，如果你想对比不同迭代次数下的训练结果，只需要实例化不同模板参数即可，编译器会分别计算。
这里还可以用类型萃取来约束模板参数，防止有人拿int去实例化而导致梯度计算变成整数除法：
static_assert(std::is_floating_point_v<T>, "T must be a floating-point type");模板匹配的思想在这里也有体现：编译期的“匹配”实际上是模板特化与重载决议在起作用。编译器拿着你给的模板参数去匹配最合适的实例化路径，这个过程和我们常说的模板匹配，本质上是同一套逻辑。
2.3 编译期容器：std::array 与 std::integer_sequence
训练需要数据容器。std::array是固定长度数组，它的存储完全在对象内部，没有动态分配，天然适合编译期使用。配合std::pair，我们可以把样本组织成“特征-标签”对：
constexpr std::array<std::pair<double, double>, 6> data = {{ {1.0, 3.0}, {2.0, 5.0}, // ... }};std::integer_sequence则是另一个利器。它可以生成一组编译期整数序列，配合包展开实现对数组的逐元素访问。比如经典的类型转换神器std::index_sequence，在编译期遍历数据时非常好用：
template <typename T, std::size_t N, std::size_t... Is> constexpr T sum_impl(const std::array<T, N>& arr, std::index_sequence<Is...>) { return ((arr[Is]) + ...); } template <typename T, std::size_t N> constexpr T sum(const std::array<T, N>& arr) { return sum_impl(arr, std::make_index_sequence<N>{}); }这套机制让编译期的数据访问和展开变得非常自然。虽然现在 C++17 的 constexpr 函数里可以直接写 for 循环，但了解integer_sequence还是必要的，因为某些元编程场合——比如实现编译期索引变换——它依然是不可替代的。
2.4 static_assert：把模型验收写成编译规则
static_assert是编译期断言的工具。它接受一个编译期可求值的布尔表达式和一条错误消息，表达式为假时编译失败。放在我们这个项目里，它的角色是“模型质量门槛”：
static_assert(std::abs(learned_w - 2.0) < 0.2, "model weight is not close enough");如果训练出来的权重偏离预期太远，编译直接失败，开发者第一时间就能看到。这相当于把机器学习里的验证集搬到了编译阶段，模型的验收标准从“跑测试脚本”变成了“编译规则”。这种思路在传统 CI 流程里没法做到，因为模型参数在编译期生成后，已经变成代码的一部分，静态断言就是对代码本身的检查，逻辑上自洽。
3. 实操：从零写一个编译期线性回归训练器
3.1 先定数据结构
我选的实验题目是标准的单特征线性回归。假设数据满足y = w * x + b，我们要从若干组(x, y)样本中，在编译期用梯度下降求出w和b。
第一步是定义样本集。为了在编译期使用，必须用 constexpr 变量：
#include <array> #include <utility> #include <cstddef> #include <type_traits> using Sample = std::pair<double, double>; using Dataset = std::array<Sample, 6>; constexpr Dataset data = {{ {1.0, 3.0}, {2.0, 5.0}, {3.0, 7.0}, {4.0, 9.0}, {5.0, 11.0}, {6.0, 13.0} }};这里我故意选了y = 2x + 1附近的点，方便最后验证训练结果。实际项目中数据集可以直接从标定测量表里抄进代码，但注意样本量不要太大，否则编译期求值步数会跟着涨。
3.2 损失函数与梯度推导
线性回归一般用均方误差（MSE）作为损失：
loss = (1/N) * Σ (w * x_i + b - y_i)^2
对w求偏导：
∂loss/∂w = (2/N) * Σ (w * x_i + b - y_i) * x_i
对b求偏导：
∂loss/∂b = (2/N) * Σ (w * x_i + b - y_i)
代码实现非常直观：
template <typename T, std::size_t N> constexpr T compute_gradient_w(const std::array<std::pair<T, T>, N>& data, T w, T b) { T grad = T(0); for (std::size_t i = 0; i < N; ++i) { T pred = w * data[i].first + b; T residual = pred - data[i].second; grad += residual * data[i].first; } return grad * T(2) / T(N); } template <typename T, std::size_t N> constexpr T compute_gradient_b(const std::array<std::pair<T, T>, N>& data, T w, T b) { T grad = T(0); for (std::size_t i = 0; i < N; ++i) { T pred = w * data[i].first + b; T residual = pred - data[i].second; grad += residual; } return grad * T(2) / T(N); }两个函数都接受了data、w、b三个参数，返回各自的偏导数。注意我把所有字面量都转成了T，这是为了避免 double 和模板类型不一致带来的隐式转换问题。
3.3 梯度下降训练循环
接下来是训练主体，一个 constexpr 函数。它要做的事很简单：初始化w=0、b=0，然后迭代固定次数，每次都按学习率更新参数：
template <typename T, std::size_t N, std::size_t Iterations> constexpr std::pair<T, T> train_linear_model( const std::array<std::pair<T, T>, N>& data, T learning_rate) { T w = T(0); T b = T(0); for (std::size_t iter = 0; iter < Iterations; ++iter) { T grad_w = compute_gradient_w(data, w, b); T grad_b = compute_gradient_b(data, w, b); w -= learning_rate * grad_w; b -= learning_rate * grad_b; } return {w, b}; }函数体里就是一个普通的 for 循环，但因为它是 constexpr，并且被用在常量表达式上下文里，C++17 编译器会在编译期把它展开执行。为什么把迭代次数放在模板参数里而不是函数参数？因为模板参数是编译期常量，编译器可以把整个循环看成“静态展开”，每个迭代的中间值理论上都可以被常量折叠，这比用运行期变量更利于编译期求值和优化。
调用方式：
constexpr auto result = train_linear_model<double, 6, 200>(data, 0.01);注意这里是constexpr auto，强制在编译期求值。如果去掉constexpr，编译器可能在运行期执行，那就失去“编译期训练”的意义了。
3.4 用 static_assert 验收模型质量
训练完成后，模型参数就在result.first（w）和result.second（b）里。我们可以在编译期做验证：
constexpr double learned_w = result.first; constexpr double learned_b = result.second; static_assert(learned_w > 1.5 && learned_w < 2.5, "w should be near 2.0"); static_assert(learned_b > 0.0 && learned_b < 2.0, "b should be near 1.0");这段断言的意义是：如果数据有问题、学习率不合适或者迭代次数不足，编译直接失败，并给出“w should be near 2.0”之类的提示。在我的实验中，200 次迭代、学习率 0.01 的情况下，w大概收敛到 1.99 左右，b大概在 1.02 附近，断言可以通过。
如果想让断言更灵活，可以写一个编译期判断损失是否降到阈值的函数：
template <typename T, std::size_t N> constexpr T compute_loss(const std::array<std::pair<T, T>, N>& data, T w, T b) { T loss = T(0); for (std::size_t i = 0; i < N; ++i) { T residual = w * data[i].first + b - data[i].second; loss += residual * residual; } return loss / T(N); } static_assert(compute_loss(data, learned_w, learned_b) < 0.01, "loss too high");这样等于在编译期跑了一遍验证集。
3.5 编译期和运行期训练结果对比
一个有意思的实验是：同一个训练函数，既在编译期求值，也在运行期调用，对比两者结果是否一致。这需要一点点技巧，C++20 里可以直接用std::is_constant_evaluated()区分上下文，C++17 下可以用带默认实参的 constexpr 函数配合if constexpr来实现大致效果。
事实上，constexpr函数在常量表达式上下文中求值时，浮点运算通常遵循严格的常量折叠规则，结果和运行期优化后的结果可能在小数点最后几位有差异，但大体一致。我在实践中发现，只要不开启-ffast-math这类激进优化，编译期和运行期的偏差可以忽略不计。
这里有一个很实用的扩展思路：如果你既想要编译期训练的参数，又想保留一个运行期重新训练的入口用于在线校准，可以写两个函数，一个返回编译期训练结果，一个返回运行期训练结果，两个函数的实现共用一套梯度计算代码。这样既保证了参数可离线编译期生成，又保留了在线更新的能力，非常适合需要现场标定的设备。
4. 进阶：把感知机模型模板化
4.1 感知机模型与训练规则
线性回归做的是回归任务，感知机则是分类任务的经典模型。它的数学形式与线性回归几乎一样：output = sign(w · x + b)，只是最后加了一个符号函数把连续值映射到类别。训练规则也非常朴素：每次迭代，对每个样本如果预测错误，就沿着正确方向修正权重。
感知机天然适合模板化，因为它的每一步都是简单的加法和乘法，没有任何矩阵分解、非线性激活这类复杂操作。把它塞进编译期，几乎不费力气。
这里的“模板匹配”思想很有意思：模型在编译期就像一套模板，每个样本进来都与当前权重做“匹配”，匹配错了就调整模板，最终留下一个能正确分类所有样本的模板参数。
4.2 编译期感知机训练器实现
我实现了一个处理二维数据的感知机，样本格式是[x1, x2, 1]，其中第三个分量是偏置项。标签用+1和-1表示。
#include <array> #include <cstddef> template <typename T, std::size_t N> constexpr std::array<T, 3> train_perceptron( const std::array<std::array<T, 3>, N>& samples, const std::array<int, N>& labels, T learning_rate, int epochs) { std::array<T, 3> weights = {T(0), T(0), T(0)}; for (int epoch = 0; epoch < epochs; ++epoch) { for (std::size_t i = 0; i < N; ++i) { T activation = T(0); for (std::size_t j = 0; j < 3; ++j) { activation += weights[j] * samples[i][j]; } int pred = activation >= T(0) ? 1 : -1; if (pred != labels[i]) { T scale = learning_rate * T(labels[i]); for (std::size_t j = 0; j < 3; ++j) { weights[j] += scale * samples[i][j]; } } } } return weights; }试着用“或”问题的数据集来验证：(0,0)标签 -1，其余三个样本(1,0)、(0,1)、(1,1)标签 +1。
constexpr std::array<std::array<double, 3>, 4> or_samples = {{ {0.0, 0.0, 1.0}, {1.0, 0.0, 1.0}, {0.0, 1.0, 1.0}, {1.0, 1.0, 1.0} }}; constexpr std::array<int, 4> or_labels = {{-1, 1, 1, 1}}; constexpr auto or_weights = train_perceptron<double, 4>(or_samples, or_labels, 0.1, 20);注意“或”问题是线性可分的，感知机可以收敛到零错误。而“异或”问题是线性不可分的，无论模板里怎么训练都不会完全正确，这也是感知机模型的经典边界。在编译期场景下，这种不可分问题会导致权重在迭代中反复震荡，编译期结果也会不稳定，所以用的时候要特别注意数据是否线性可分。
4.3 在编译期完成二分类推理
训练完成后，我们可以把推理函数也做成 constexpr，放在编译期验证：
template <typename T> constexpr int predict(const std::array<T, 3>& weights, T x1, T x2) { T activation = weights[0] * x1 + weights[1] * x2 + weights[2]; return activation >= T(0) ? 1 : -1; } static_assert(predict(or_weights, 1.0, 0.0) == 1, "OR(1,0) should be 1"); static_assert(predict(or_weights, 0.0, 0.0) == -1, "OR(0,0) should be -1");这是整个项目里最顺滑的一段。训练在编译期完成，推理也在编译期验证完毕，生成的二进制里只有几个权重常量，运行时调用predict就是三次乘加和一个分支判断，开销几乎可以忽略。对这种体量的推理任务，编译期模型就是一个表驱动的模板匹配器，模型参数本身就是模板的一部分。
5. 踩坑实录：开发中常见问题与排查技巧
5.1 编译期调试的三板斧
编译期代码的调试体验比普通代码差很多，因为std::cout不能用在常量表达式里，你不能在编译期“打印”中间值。我总结出三个土办法：
办法一：利用不完整类型触发错误显示值。
定义一个没有定义的模板结构体，然后实例化它，编译器报错时会把模板实参显示在错误消息里：
template <auto V> struct PrintValue; constexpr double temp = learned_w; PrintValue<temp> debug_w; // 编译报错：aggregate 'PrintValue<temp> debug_w' has incomplete type错误信息里会带着temp的实际数值，这在想快速看一眼编译期变量值的时候很管用。缺点是编译会中断，只能一个一个查。
办法二：不断收窄 static_assert 范围。
把断言写成多段，比如先断言w > 0.0，再断言w > 1.0，再断言w > 1.5，通过观察哪条断言失败，就能判断w大致落在哪个区间。这像是二分查找，虽然笨，但非常可靠。
办法三：注释切片法。
把模板中的某一段抽出来，放到一个独立的 constexpr 变量里测试，确认无误后再放回去。编译期求值一旦卡住，先砍代码量，把训练循环的次数改小到 1，看数据流向是否正常，再逐步放大。
5.2 常见编译错误速查表
我整理了几个高频错误，基本都是模板元编程和 constexpr 混合场景下的通病：
| 错误现象 | 根本原因 | 解决方案 |
|---|---|---|
expression did not evaluate to a constant | 编译器在常量求值时步数或内存超限 | 减小迭代次数；调大-fconstexpr-steps/-fconstexpr-depth |
recursive template instantiation exceeds maximum depth | 递归模板没有及时终止或深度过大 | 检查特化出口；用constexpr循环代替递归；调大-ftemplate-depth |
call to non-constexpr function | 在常量表达式里调用了非 constexpr 接口 | 检查标准库版本；std::array::operator[]必须 C++17 及以上 |
| 编译时间爆炸 | 模板参数组合过多或迭代展开过大 | 减少样本、迭代次数；把外层循环改为运行期 |
| 浮点数结果不稳定 | 学习率过大或数据尺度差异大 | 调整学习率；对输入特征做缩放 |
举一个具体例子：C++14 编译环境下，在 constexpr 函数里使用data[i].first会直接报“std::pair::first不是 constexpr”之类的错误。原因是 C++14 标准下std::pair的成员访问在常量表达式里还没有被广泛支持，必须换成 C++17 才行。这种“能不能在编译期用”的问题，往往是标准库里某个函数是否标记 constexpr 的问题，查 cppreference 是最快的。
5.3 编译时间与内存观察
编译期训练的代价非常直观：编译时间变长。我的实验里，一个 6 样本的线性回归，200 次迭代，在普通-O2编译下几乎感觉不到额外耗时；但把样本加到 50 个、迭代加到 5000 次，编译时间会明显增加。如果是模板递归实现（比如某些老式元编程写法），深度每加一层，编译时间可能是线性甚至更差的增长。
常用的 GCC/Clang 编译选项有：
-ftemplate-depth=1024：增加模板递归深度上限。-fconstexpr-depth=10000：增加常量表达式递归深度上限。-fconstexpr-steps=1000000：增加编译期常量求值的步数上限。-fconstexpr-loop-limit：控制常量表达式循环展开上限。
注意，这些选项的具体名称和默认值会随编译器版本而变，最好查一下当前版本的文档。我的经验是：先用默认参数跑，遇到报错再针对性调大，不要一股脑地调满，否则编译时间可能从几秒变成几分钟。
5.4 可读性与可维护性建议
编译期代码最容易被人诟病的就是可读性差。我自己的做法是：
第一，把训练数据单独抽成一个头文件。数据是业务的一部分，训练代码是算法的一部分，两者分开。后续换数据、调样本，不需要动模板代码。
第二，用类型别名封装模板参数。比如定义：
template <typename T, std::size_t N, std::size_t Iterations> struct LinearRegressionConfig { using Scalar = T; static constexpr std::size_t SampleCount = N; static constexpr std::size_t MaxIterations = Iterations; };这样实例化时传一个LinearRegressionConfig<double, 6, 200>，比直接传三个裸参数要清晰得多。
第三，把训练结果集中放在一个命名空间下。比如namespace trained_model { constexpr double w = /*...*/; }，所有使用模型的地方都从该命名空间取常量，避免散落一地。
第四，给每个 static_assert 写清楚消息。因为编译失败时开发者第一眼看到的就是这条消息，写一个好消息比写一堆文档管用。比如static_assert(loss < 0.01, "linear regression model failed to converge below 0.01 MSE")，把模型名、指标、阈值都写进去。
还有一个小技巧：如果担心某个 constexpr 函数在编译期求值太慢，可以把它改成运行期函数，再写一个包装函数在编译期调用。比如用std::is_constant_evaluated()判断上下文，编译期走快速路径（比如迭代次数减半），运行期走完整路径。C++20 可以直接用，C++17 可以通过默认实参 +if constexpr模拟出类似效果。
个人体会与后续扩展
这套“模板编译期机器学习”搞下来，我最大的体会有两点。第一点，模板元编程和机器学习在抽象层面是相通的：它们都是在“模式匹配 + 迭代修正”的框架下工作，模板的实例化就是匹配，constexpr 函数里的梯度下降就是修正，只不过前者在编译期，后者在运行期。理解了这一点，你对模板和机器学习都会有更深层的认识。第二点，编译期计算不是万能的，它适合那些数据量小、模型简单、参数明确的场景，一旦越过这个边界，编译器会用漫长的编译时间和令人崩溃的错误信息来教做人。
如果后续继续扩展，我会尝试把编译期决策树、编译期 KNN 也写出来，甚至用宏或代码生成器自动把一个简单的 Python 模型转换成 C++ 模板代码。最后再分享一个小技巧：如果你的目标平台连浮点单元都没有，可以试试把所有运算改成int或fixed-point，编译期照样可以训练出系数，运行时用整数乘加就能完成推理，这在很多低成本单片机上是个非常实用的方案。
