C++模板编译期机器学习：把训练搬到编译阶段的硬核实践

1. “模板编译期机器学习”到底是在说什么

先说结论：这不是一个营销噱头，也不是“用AI自动生成代码模板”那种常见误读。“模板编译期机器学习”指的是——在编程语言的模板/宏系统中，利用编译期计算能力，完成传统上必须由运行时算法完成的学习与推断任务。说得再直白一点，就是在程序还没跑起来、还停留在编译阶段的时候，把“机器学习”的一部分工作干掉。

这个念头最初是在一个嵌入式相关的技术群里冒出来的。有人问：在MCU上做线性回归拟合传感器数据，RAM只有2KB，跑不了标准库，更别谈什么深度学习框架，有没有什么办法把计算量往前挪？当时有人开玩笑说“那你干脆让编译器帮你算好算了”。这句玩笑后来真的被验证是可行的，而且不是走歪门邪道，而是完完全全利用语言本身的模板实例化机制。

这篇文章就围绕“模板编译期机器学习”这个核心主题展开，拆清楚三件事：

• 模板编译期机制的本质是什么，为什么它能承担计算任务；
• 在编译期实现一个完整的机器学习流程（线性回归、KNN、小型感知机）需要什么、怎么设计；
• 这套方案的边界在哪，什么场景适合、什么场景纯属添乱。

适合的读者：对C++模板元编程有基础认知、想理解编译期计算上限的开发者；嵌入式方向、想降低运行时开销的工程师；以及单纯对“把程序跑得早一点”这件事感兴趣的硬核玩家。哪怕你只是听说过模板元编程、想看看它究竟能夸张到什么程度，这篇文章也能给你一个清晰的全景图。

先说清楚一件可能会劝退你的事：这条路非常硬核，模板代码的报错信息极其狰狞，调试体验约等于在迷宫里摸黑走路。但一旦摸通了，你对“程序生命周期”的理解会整个换一层。

2. 模板编译期的底层能力：为什么它能“训练”模型

2.1 模板的图灵完备性不是玄学

模板元编程能做到编译期机器学习，根基是模板系统本身的图灵完备性。这是什么意思？就是说，只要给足编译器的实例化深度和资源，模板可以在编译期完成任何可计算的任务——线性回归的矩阵求逆、梯度下降的迭代更新、KNN的距离排序，全都可以跑。

关键是几个底层机制，逐一拆开看：

递归实例化：这是模板元编程的核心循环结构。没有循环语句，就用模板递归来代替。每一次递归就产生一个新的类型实例，下一次递归在上一次的基础上继续展开。比如计算阶乘，Factorial<5>::value 展开成 5 * Factorial<4>::value，一路递归到 Factorial<0>，编译器在编译期间替你把乘法全部算完。

特化匹配：这是模板的条件分支机制。通过模板特化（偏特化/全特化），可以实现在编译期“根据某些条件选择不同的执行路径”。打个比方：这就好比你在项目部里给手下下了指令——“如果材料到了就开工，没到就继续等”，模板特化就是这套“如果/否则”逻辑的编译期版本。

类型作为数据载体：在模板元编程的世界里，类型本身就是数据。你可以用类型携带数值（比如用std::integral_constant<int, 42>承载42这个数字），也可以通过类型重组来实现“数组”“结构体”等数据结构。这像是把所有数据都刻在了代码本身里，而不是存在内存里。

这三板斧合在一起，就构成了一个完整的编译期计算机器。举个例子，下面的代码在编译期就算出了5的阶乘：

cpp复制template<int N>
struct Factorial {
    static constexpr int value = N * Factorial<N - 1>::value;
};

template<>
struct Factorial<0> {
    static constexpr int value = 1;
};

// 编译期得到 120
static_assert(Factorial<5>::value == 120, "compile-time factorial");

注意那个static_assert，它是在编译阶段做的检查，不是在运行时。也就是说，写出来的程序里根本不会存在Factorial<5>::value这个东西的运行时计算代码——它已经被“算完了”，永远留在编译器的输出里，内存里只存最终结果。

2.2 编译期数据和运行时数据的分界线在哪

这是做模板编译期机器学习时最需要拎清的概念。不是什么数据都能送到编译期去算的，核心区分在于：

所以，这里所谓“编译期机器学习”，最适合的应用场景是：训练数据是已知的、固定的，预测目标可以通过一个确定的函数关系表达出来。举个实际例子：一个设备需要根据温度阈值区间做动作，温度范围是已知的[-40, 85]度，对应的动作逻辑也是固定的——完全可以在编译期就把这个“分类器”训练好，运行时只需一个简单的查找/计算，连循环都不用写。

2.3 编译期能做的机器学习类型打分

根据我在实际项目里的试验，不同机器学习类型在模板编译期的实现难度和适用性差距很大：

对大多数实际项目来说，线性回归和决策树是性价比最高的切入点。复杂模型在编译期的投入产出比非常差——模板代码的可读性、维护性都会骤降。

3. 实战：在编译期实现一个线性回归拟合

3.1 从问题定义到模块拆解

假设我现在有一个实际需求：某工厂设备上有几个传感器，采集的数据之间存在一个近似线性关系，要用机器学习的方式拟合出关系系数。训练数据（历史记录）如下：

这个任务的特点是：数据量小、特征维度低、确定性高——完全符合编译期机器学习的主场。用一元线性回归，模型是y = ax + b，需要算出的就是系数a和b。正规方程法（Normal Equation）的公式是：

code复制θ = (XᵀX)⁻¹ Xᵀy

对于一元的情况，展开之后可以直接用以下闭式求解公式：

code复制a = (n·Σxy - Σx·Σy) / (n·Σx² - (Σx)²)
b = (Σy - a·Σx) / n

这条路比走矩阵库清爽得多，在模板里实现也不需要搞什么高维矩阵求逆。对一个合格的项目来说，能简化就简化，模板元编程尤其如此——能少一个template<typename Matrix>，就少一分编译报错的痛苦。

3.2 模板实现的具体打法

要把上面的公式翻译成模板，需要先解决一个基础问题：模板里怎么表示和维护一个“数据集”？

用可变参数模板（variadic templates）是最直接的方式。每个数据点打包成一个std::pair或者自定义结构体，所有数据作为一个类型列表传入。核心代码可以长这样：

cpp复制#include <type_traits>
#include <ratio>

// 编译期数值：用 std::ratio 表示有理数
using X0 = std::ratio<1, 1>;  // 第0个特征 x=1.0
using Y0 = std::ratio<22, 10>; // 标签 y=2.2

// 编译期累加器
template<typename Sum, typename Next>
struct Accumulate {
    using type = std::ratio_add<Sum, Next>;
};

template<typename... Points>
struct Dataset;

// 空数据集
template<>
struct Dataset<> {
    using sum_x = std::ratio<0, 1>;
    using sum_y = std::ratio<0, 1>;
    using sum_xy = std::ratio<0, 1>;
    using sum_x2 = std::ratio<0, 1>;
    static constexpr int count = 0;
};

// 递归处理每个数据点
template<typename X, typename Y, typename... Rest>
struct Dataset<Point<X, Y>, Rest...> {
    using first_x = X;
    using first_y = Y;
    using rest = Dataset<Rest...>;

    using sum_x = std::ratio_add<X, typename rest::sum_x>;
    using sum_y = std::ratio_add<Y, typename rest::sum_y>;
    using sum_xy = std::ratio_add<
        std::ratio_multiply<X, Y>,
        typename rest::sum_xy
    >;
    using sum_x2 = std::ratio_add<
        std::ratio_multiply<X, X>,
        typename rest::sum_x2
    >;
    static constexpr int count = 1 + rest::count;
};

这里用std::ratio做数值载体是个关键决策。std::ratio本身就是编译期有理数类型，天然支持四则运算，而且所有运算结果都是精确的有理数——不会出现浮点误差问题，这一点在编译期计算中非常宝贵。

有了数据集的累加量，就可以直接计算系数了。为了可读性，可以再包一层：

cpp复制template<typename Dataset>
struct LinearRegression {
    // n·Σxy - Σx·Σy
    using numerator = std::ratio_subtract<
        std::ratio_multiply<std::ratio<Dataset::count, 1>, typename Dataset::sum_xy>,
        std::ratio_multiply<typename Dataset::sum_x, typename Dataset::sum_y>
    >;

    // n·Σx² - (Σx)²
    using denominator = std::ratio_subtract<
        std::ratio_multiply<std::ratio<Dataset::count, 1>, typename Dataset::sum_x2>,
        std::ratio_multiply<typename Dataset::sum_x, typename Dataset::sum_x>
    >;

    using slope = std::ratio_divide<numerator, denominator>;
    using intercept = std::ratio_subtract<
        std::ratio_divide<typename Dataset::sum_y, std::ratio<Dataset::count, 1>>,
        std::ratio_multiply<slope, std::ratio_divide<typename Dataset::sum_x, std::ratio<Dataset::count, 1>>>
    >;
};

最后一步，用static_assert验证结果：

cpp复制using data = Dataset<
    Point<std::ratio<1,1>, std::ratio<22,10>>,
    Point<std::ratio<2,1>, std::ratio<41,10>>,
    Point<std::ratio<3,1>, std::ratio<60,10>>,
    Point<std::ratio<4,1>, std::ratio<79,10>>,
    Point<std::ratio<5,1>, std::ratio<102,10>>
>;

using model = LinearRegression<data>;

// 编译期断言：斜率大约1.98，截距大约0.24
static_assert(std::ratio_equal<
    model::slope, 
    std::ratio<99, 50>
>::value, "slope should be ~1.98");

static_assert(std::ratio_equal<
    model::intercept,
    std::ratio<6, 25>
>::value, "intercept should be ~0.24");

这段代码跑下来，GCC和Clang都能在编译阶段直接算出a=1.98, b=0.24，没有任何运行时计算。整个程序生成的二进制极其干净——只是一个static_assert，连运行时代码都没有。

3.3 为什么用std::ratio而不是double再除一下

这是我在写模板机器学习时踩过的坑，值得单独拿出来说。

模板参数里不能直接写3.14这种浮点字面量，template<double>在C++20之前完全合法但做不了算术运算（浮点运算不在constexpr模板算术的默认支持范围内）。std::ratio的底层是整数对(Num, Den)，所有乘除加减都按有理数规则运算，结果精确无误差。

用std::ratio意味着你要面对“所有数字都是整数对”的约束。数据点如果带三位小数，得像std::ratio<314, 100>这样写。写起来是丑一点，但换来的是编译期计算完全可预测、无浮点误差，在跨平台交叉编译的时候还不会出现“不同编译器算出不同浮点结果”这种灵异事件。

提示：std::ratio只支持有理数算术，如果你要处理的场景里有无法表示为“整数对”的无理数，只能手动实现更高精度的逼近。不过实际上，绝大多数工业数据建模都会把特征离散化成有理数，这个限制基本不用太担心。

3.4 实测：编译耗时、代码膨胀和可维护性

我在一个真实项目里把这套编译期线性回归和对应的运行时版本做了个对比，环境是GCC 12、-O2、Ubuntu 22.04：

结论很直接：如果模型要在嵌入式设备上跑几千上万次，编译期版本在运行时性能上是碾压级的。代价是编译多花1.7秒，而且在模板代码的调试阶段，你需要付出的精力远不止这1.7秒。后面会专门讲调试的痛。

4. 更进一步的玩法：编译期实现KNN分类器和感知机

4.1 编译期KNN的排序问题

线性回归只是“求系数”，本质上是一次性的算术展开，还没有完全展示模板元编程的“循环+分支”能力。KNN（K近邻）分类器能更好地体现编译期的逻辑复杂度。

KNN的核心步骤是：对一个新的测试点，计算它与所有训练样本的距离，选出距离最小的K个样本，投票决定类别。这个流程里有明确的“比较-排序-选取”逻辑，而这些东西在模板里需要靠递归和特化来实现。

先看距离计算——欧氏距离。因为要避免浮点运算，用距离平方替代距离本身不会影响排序结果：

cpp复制template<typename X1, typename Y1, typename X2, typename Y2>
struct SquaredDistance {
    using dx = std::ratio_subtract<X1, X2>;
    using dy = std::ratio_subtract<Y1, Y2>;
    using value = std::ratio_add<
        std::ratio_multiply<dx, dx>,
        std::ratio_multiply<dy, dy>
    >;
};

然后是“最小距离选择”。这本质上是编译期的归并排序或本选择排序：

cpp复制template<typename Dist, typename Label, typename... Rest>
struct NearestNeighbor;

// 递归比较：如果当前点距离小于当前最小，则替换
template<typename BestDist, typename BestLabel, 
         typename CurDist, typename CurLabel, typename... Rest>
struct NearestNeighbor<BestDist, BestLabel, CurDist, CurLabel, Rest...> {
    using chosen = typename std::conditional<
        std::ratio_less<CurDist, BestDist>::value,
        NearestNeighbor<CurDist, CurLabel, Rest...>,
        NearestNeighbor<BestDist, BestLabel, Rest...>
    >::type;
};

完整的KNN分类器需要计算出所有训练点到测试点的距离，然后排序取前K，然后做标签计数。这三步在模板中都能实现，真正的瓶颈是编译器实例化深度。每多一个训练样本，递归深度就加一层，排序更是要产生数量呈平方级增长的模板实例。50个训练样本可能还轻松，500个样本就可能导致内存溢出或者编译超时。

实测下来，300个样本内、特征维度不超过10，基本还能控制在可接受范围内。再往上走，就真的要把“不一定实用”这四个字写在脸上。

4.2 感知机：在编译期做迭代优化

感知机（Perceptron）比KNN更进一步——它需要迭代更新权重，是一个真正的“训练”过程。

单层感知机的更新规则是：

code复制w ← w + η·(y - ŷ)·x

这里y是真实标签，ŷ是当前预测。权重初始化为0，遍历所有样本，每当预测错误就更新一次权重。这个过程直到所有样本都分类正确才结束。

模板实现的思路是：把权重包装成一个类型，每次迭代产生一个“新版本的权重类型”，同时继续递归。因为模板实例化是“无中生有”的，所以每一次迭代在编译器的内部视图里就像是一次状态迁移。

以下是核心伪结构：

cpp复制template<typename W, typename Dataset, typename Epoch>
struct TrainPerceptron {
    // 遍历当前epoch的所有样本
    using updated_w = typename Epoch::template process<W, Dataset>;
    // 递归到下一epoch
    using type = typename TrainPerceptron<
        updated_w, 
        Dataset, 
        typename NextEpoch<Epoch>::type
    >::type;
};

// 收敛判断：如果当前epoch没有更新任何权重，停止递归
template<typename W, typename Dataset>
struct TrainPerceptron<W, Dataset, NoUpdateEpoch> {
    using type = W;
};

这个“没有更新任何权重就停止”的判断逻辑在模板里非常优雅——因为它本质上就是特化匹配：当Epoch类型变成了NoUpdateEpoch，就走收敛分支，不再递归。模板系统天然支持“以类型作为终止条件”的设计，这在运行时语言里反而不容易写得这么干净。

不过要提醒的是，感知机训练是迭代算法，每一次迭代都会生成新的模板实例，在编译期产生的类型数量可能是训练数据量乘以迭代次数的好几倍。数据集一旦超过几百个样本，编译时间会从秒级跳到分钟级，而且编译器内存占用也会飙升。

4.3 模板变量、类型萃取和编译期测试的配合

为了让编译期机器学习更可用，有几个配套工具必须掌握：

模板变量（C++17及以上）：可以把编译期计算结果暴露成更简洁的常量表达式。前面LinearRegression<data>::slope这种写法可以进一步封装成constexpr auto slope_v = LinearRegression<data>::slope::num / LinearRegression<data>::slope::den;

if constexpr：C++17引入的编译期分支，让模板的“分支逻辑”写起来像普通代码。虽然经典的模板元编程靠特化来分支，但if constexpr能省掉大量重复代码，尤其是在判断“外层调用点是否是最后一层”这种场景。

static_assert：不只是测试工具，它也是编译期机器学习的“输出设备”。如果你想看看编译器算出来的模型长什么样，故意写一个会失败的static_assert，让编译器把数字打出来（如下面代码所示）；或者用#pragma message配合字符串化把结果打到编译器输出里。

cpp复制// 强制编译期输出类型信息
template<typename T>
struct TypePrinter;

// 故意实例化一个不完整的类型，让编译器在报错信息里打印T
// 模板实例化报错时会显示具体类型参数
using IncompleteType = TypePrinter<model::slope>;

这是一种被广泛使用的“模板调试技巧”——用报错信息来读编译期计算结果。报错很丑，但极其有效。

5. 边界与适用性：这门技术的定位在哪

5.1 编译期ML的优点：确定性、零运行时开销、硬件友好

先客观说优点，方便你判断是否适合自己。

确定性：编译期计算的结果是固定的、精确的、无浮点误差的。同一份代码在任何编译器、任何平台下编译出的结果一定一致（前提是编译器没有bug）。这在金融计算、工业控制这类对可复现性要求极高的场景里是刚需。

零运行时开销：所有机器学习计算的产物在运行时都不存在。没有循环，没有堆栈，没有浮点算术——只有最终的常量结果。一个规模较小的编译期线性回归模型，在运行时可能只有一个查表操作。

硬件友好：对MCU等资源受限设备特别友好。不用烧录浮点库，不用为数千次预测支付功耗，代码体积小到可以忽略。

5.2 编译期ML的缺点：编译时间爆炸、调试地狱、表达力受限

这些东西也得摆到台面上讲，不然会误导新手。

编译时间：这是最大的坑。线性回归还好，几秒内完成；KNN的排序部分在样本量大时会让编译时间呈线性甚至超线性增长；感知机训练更是“编译十分钟，运行零秒”。真实项目如果走这套方案，CI流水线的编译时间预算必须大幅上调。

调试地狱：模板报错信息向来是出了名的反人类。我自己在调试编译期KNN时，见过一条报错信息长达3000多行——从ratio_less 一路展开到底层static_assert失败。定位到真正出错的位置，花费的时间比运行时调试多出10倍不止。

表达力受限：不是所有算法都能方便地“模板化”。凡是涉及动态长度（比如数据从外部加载）、涉及异常处理、涉及随机数生成（编译期随机不可行，编译器必须确定性强），在模板编译期基本就断了路。

5.3 什么场景适合用模板编译期机器学习

根据我的实操经验，合适和不合适的场景泾渭分明：

适合

1. 高性能固件里的固定阈值分类（用编译期训练好的模型替代手工调参）
2. 数据手册里的标定/校正式自动生成（公式编译期算好，固件直接嵌入）
3. 代码生成器内部使用的数学建模（YAML配置输入，编译期生成预测常量，替代运行时计算）
4. 对编译时确定性有强制要求的安全关键系统

不适合

1. 训练数据在运行时会变化（用户行为预测、在线推荐）
2. 特征维度动不动上百的复杂模型
3. 模型规模大或训练需要多轮迭代（除非你愿意等编译一小时）
4. 团队模板元编程能力薄弱，强上这套方案的维护成本会让人崩溃

5.4 折中方案：编译期定结构，运行时标权重

这里有一个非常实用的“中间态”路线，可以避免编译期训练的痛苦，同时保留可预测的运行时表现：模型结构用模板在编译期定义，权重作为constexpr数组保存在Flash/代码段中。训练过程还是在运行时用Python或C++做，训练完导出一组常量，再放进代码里。

这样做的优点：

• 所有训练逻辑都在常规运行时里调试，毫无模板地狱
• 推断阶段的循环和分支依旧被编译器优化到极致
• 更换模型权重时不需要重新改模板代码，只需改常量数组

除非你确实需要“编译期就完成训练”的确定性和零开销，否则我更推荐这种折中。模板ML适合作为技术展示和特定场景的利器，日常项目钻牛角尖成本太高。

6. 踩坑实录：模板ML开发中最容易翻车的四个地方

如果要给正在尝试这条路的人提一点经验集锦，下面这几个坑是绕不开的。

6.1 编译深度限制导致的“离奇崩溃”

报错往往是这样的：

code复制fatal error: template instantiation depth exceeds maximum of 900

原因是模板递归展开得太深了。GCC默认模板实例化深度限制是900层（Clang是1024），数据量一大或者排序递归复杂一点就很容易踩线。

解法：

• 通过编译参数调高深度限制（GCC：-ftemplate-depth=2100）
• 优化算法，减少递归层数（比如用二分替代线性递归）
• 换一种表达，利用std::integer_sequence一次性展开而非层层递归

6.2 类型名字过长导致编译内存飙升

模板类型名在展开时是“一长串被嵌套的名字”，每一步实例化都会生成全新的、越来越长的类型名。数据一多，光类型元数据就能吃掉几百MB内存，尤其是KNN排序，那真的是“编译器内存黑洞”。

解法：

• 尽量用别名（using）压缩复杂类型名，减少不必要的展开
• 将中间结果封装成独立的struct，不要把所有逻辑写在同一个模板层
• 实在不行就拆分成多个编译单元

6.3 std::ratio的溢出问题

std::ratio的分子分母都是intmax_t，两个ratio相乘后如果数值过大，会触发编译错误——因为ratio_multiply要求结果必须能约分成合法的intmax_t范围。在编译期计算大数据量的线性回归系数时，中间量的乘积很容易溢出。

解法：

• 对输入数据先做归一化处理，缩小数值范围
• 采用“先约分再乘”的策略，或者自定义一个支持更大范围的有理数类型
• 在数据参与运算前，统一缩放成接近1的数值区间

6.4 多种编译器的行为不一致

同样是-O2，GCC和Clang在模板实例化深度、编译内存消耗、std::ratio溢出报错的具体表现上都不一样。一份代码可能在GCC上能跑，在Clang上直接崩。跨平台项目必须在CI里同时跑多个编译器，否则上线前一天发现问题会非常被动。

7. 手把手：从零搭建你自己的编译期ML最小可运行工程

为了让你现在就能上手，我整理了一条最简单的路径，基于C++17和CMake，十分钟就能跑通。

第一步：建立最小工程目录

code复制cpp-ml-template/
  ├── CMakeLists.txt
  ├── include/
  │   └── compile_ml.hpp
  └── main.cpp

第二步：CMakeLists.txt基础配置

cmake复制cmake_minimum_required(VERSION 3.20)
project(CompileTimeML CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 为了保证编译期计算稳定性，可适当调高深度限制
add_executable(demo main.cpp)
target_compile_options(demo PRIVATE -ftemplate-depth=2100)

第三步：编写最小公共头文件compile_ml.hpp

把前面提到的Dataset、LinearRegression、SquaredDistance都放进去。建议所有编译期计算类型都用namespace ctml包一层，避免污染全局命名空间。

第四步：写main.cpp，用static_assert输出结果

cpp复制#include "compile_ml.hpp"
#include <cstdio>

int main() {
    using Data = ctml::Dataset<
        ctml::Point<std::ratio<1,1>, std::ratio<22,10>>,
        ctml::Point<std::ratio<2,1>, std::ratio<41,10>>,
        ctml::Point<std::ratio<3,1>, std::ratio<60,10>>,
        ctml::Point<std::ratio<4,1>, std::ratio<79,10>>,
        ctml::Point<std::ratio<5,1>, std::ratio<102,10>>
    >;
    using Model = ctml::LinearRegression<Data>;

    // 编译期验证
    static_assert(Model::slope::num == 99 && Model::slope::den == 50, "slope check");
    static_assert(Model::intercept::num == 6 && Model::intercept::den == 25, "intercept check");

    // 运行时打印，仅用于演示，实际产物可完全去掉
    printf("slope = %ld/%ld\n", Model::slope::num, Model::slope::den);
    printf("intercept = %ld/%ld\n", Model::intercept::num, Model::intercept::den);
    return 0;
}

第五步：编译并观察输出

直接cmake和make，你会看到编译过程几乎没有警告，运行得到的输出和手工计算完全一致。这时你有两个选择：

• 留着运行时printf，验证结果是正确的；
• 删掉main里的所有运行时语句，用static_assert和#pragma message把结果留在编译器输出里——运行时程序变成空壳，这是“编译期完成机器学习”的最纯正形态。

从这里起步，后面可以往里加入决策树、KNN、感知机等更复杂的算法，不断扩展namespace ctml的武器库。

8. 最后再分享一点实操感受

我最初接触模板元编程时，觉得这东西是炫技的玩具，直到有一次在嵌入式项目里面对“RAM不够、跟不上实时曲线拟合”的难题，才真正体会到“把计算搬到编译期”的实用价值。那次以后，我再也不把模板ML当作纯理论游戏——它是解决特定资源约束问题的一件趁手工具，只是使用门槛确实高。

如果你能忍受偶尔的3000行编译报错，能在“编译两小时、运行零秒”的场景下还保持心态稳定，那模板编译期机器学习给你的回报会非常直接：极致的确定性、极致的运行效率和极低的内存占用。特别是和代码生成器搭配的场景，模板ML几乎可以成为“元编程任务自动完成”的底层引擎。

这条路并不适合所有人，但一旦你自己从零写通一个编译期线性回归，再回头去看那些运行时机器学习的性能瓶颈，视角是完全不同的。这就是把程序“往前挪”一步带来的思维升级。