前言

模板元编程（template metaprogramming，TMP）指的是利用模板的实例化机制，在编译期完成计算或生成类型。它的产物不是运行时的数据，而是常量、类型、函数重载集合，甚至整段可执行代码的形状。理解它之后，很多「运行时的分支」可以提前到编译期消失，很多「靠约定保证」的类型约束可以变成编译错误。

常见的误解是把它等同于「写很复杂的模板」或者「炫技」。实际上模板元编程的出发点非常务实：容器需要针对不同类型生成代码，算法需要在不损失类型信息的前提下组合，库作者需要在编译期检查用户是否传了正确的类型。标准库里的std::vector、std::function、std::tuple、std::ratio都建立在这套机制上。它不是语言之外的魔法，而是模板规则的自然结果。

另一个误解是「模板元编程已经被constexpr取代，不用学了」。两者解决的是不同层面：constexpr函数计算的是值，模板计算的是类型和代码结构。if constexpr和 concepts 确实让很多旧技巧不再必要，但只要需要「根据类型选择不同的实现」「在编译期遍历一个类型列表」「对参数包做变换」，模板仍然是唯一的基础设施。

本文从「值计算」和「类型计算」两条线讲起，对比模板递归、constexpr函数、if constexpr三种写法，最后给出类型列表与 SFINAE 的完整示例。代码以 C++17 为基准；涉及 C++20 的地方会单独标注。本机没有 C/C++ 工具链，所有代码按标准语义人工推演，未编译、未运行。

一、模板元编程到底在算什么

模板实例化是一个纯编译期过程。给定模板和实参，编译器生成一个具体的实体：类模板生成一个类，函数模板生成一个函数，变量模板生成一个变量。这个过程中可以做的事情包括：

• 
  
• 值计算：非类型模板参数、static constexpr成员、constexpr函数，都能在编译期得到常量。
• 
  
• 类型计算：通过偏特化和递归，从一个类型推导出另一个类型，例如「去掉引用」「找到第一个满足条件的类型」。
• 
  
• 条件选择：根据编译期条件选择不同的类型或函数，例如std::conditional、std::enable_if。
• 
  
• 结构展开：参数包展开、折叠表达式，把任意长度的类型或值序列变换成目标形式。
• 
  

模板元编程在实践中被认为是图灵完备的：在没有实现资源限制的前提下，它可以表达任意可计算函数。但「能算」不等于「该算」——所有计算都发生在编译期，代价是编译时间、内存和错误信息的可读性。编译器为此设置了模板递归深度、常量求值步数等上限，超出后直接报错。

一个关键区别要先讲清楚：模板元编程里的「失败」通常是编译错误，不是未定义行为。例如在常量表达式里发生有符号整数溢出，该表达式不满足核心常量表达式的条件，程序一般直接编译失败；而在运行时发生同样的溢出才是未定义行为（undefined behavior，UB）。两者的后果完全不同，不能混为一谈。

二、从模板递归到 constexpr：同一件事的三种写法

最经典的入门例子是阶乘。模板版本用类模板递归展开，用全特化提供终止条件：

// 适用于 C++17
#include <cstddef>

template<unsigned N>
struct Factorial {
static constexpr unsigned long long value =
static_cast<unsigned long long>(N) * Factorial<N - 1>::value;
};

template<>
struct Factorial<0> {
static constexpr unsigned long long value = 1ULL;
};

static_assert(Factorial<5>::value == 120ULL, "5! 应为 120");

这里有两个必须存在的部分：递归定义和终止特化。编译器实例化Factorial<5>时，需要Factorial<4>，一路到Factorial<0>才停止。如果漏掉全特化，实例化不会终止，最终触碰-ftemplate-depth上限并报错（具体上限值随编译器与版本变化）。

C++11 起可以用constexpr函数做同样的事，C++14 又允许在constexpr函数里写循环和局部变量：

// 适用于 C++17
constexpr unsigned long long factorial(unsigned n) {
unsigned long long result = 1ULL;
for (unsigned i = 2; i <= n; ++i) {
result *= static_cast<unsigned long long>(i);
}
return result;
}

static_assert(factorial(5) == 120ULL, "5! 应为 120");

同样是编译期求值，constexpr函数的写法更接近普通代码，错误信息也更友好。C++17 的if constexpr进一步让「按类型分支」不必依赖重载和特化：

// 适用于 C++17
#include <string>
#include <type_traits>

template<class T>
std::string describe(const T&) {
if constexpr (std::is_integral<T>::value) {
return "integral";
} else if constexpr (std::is_floating_point<T>::value) {
return "floating point";
} else {
return "other";
}
}

if constexpr的关键语义是：条件必须是常量表达式，未被选中的分支不会实例化。这一点和普通if有本质区别——普通if的两个分支都会被编译，只是运行时走其中一条。正因如此，if constexpr可以写出「对某些类型本来就不合法」的代码，只要那段代码位于未选中分支即可。

三种写法如何选择：

需要提醒：constexpr函数不一定在编译期执行。只有在常量表达式上下文（如static_assert、数组长度、非类型模板实参）中调用时，才强制编译期求值；在运行时调用就是普通函数。模板递归则没有这个选择，它一定发生在编译期。

三、类型级编程：类型列表、trait 与 SFINAE

值计算只是热身，模板元编程真正不可替代的地方是类型级编程。标准库的 type traits 就是典型：std::is_integral<T>、std::remove_reference<T>、std::conditional<B, T, F>都在类型层面做判断和变换。

一个最小的类型列表可以这样写：

// 适用于 C++17
#include <cstddef>
#include <type_traits>

template<class... Ts>
struct TypeList {};

// 计算列表长度
template<class List>
struct Size;

template<class... Ts>
struct Size<TypeList<Ts...>>
: std::integral_constant<std::size_t, sizeof...(Ts)> {};

// 判断列表是否包含某个类型
template<class List, class T>
struct Contains;

template<class T, class... Rest>
struct Contains<TypeList<T, Rest...>, T> : std::true_type {};

template<class T, class First, class... Rest>
struct Contains<TypeList<First, Rest...>, T>
: Contains<TypeList<Rest...>, T> {};

template<class T>
struct Contains<TypeList<>, T> : std::false_type {};

static_assert(Size<TypeList<int, double, char>>::value == 3, "");
static_assert(Contains<TypeList<int, double>, double>::value, "");
static_assert(!Contains<TypeList<int, double>, char>::value, "");

Contains用了两个偏特化加一个全特化：第一个匹配「首元素就是目标类型」，第二个在首元素不匹配时剥掉首元素继续递归，最后一个处理空列表。这里有一个模式匹配的细节——第一个偏特化Contains<TypeList<T, Rest...>, T>要求两个位置的T是同一个类型，因此它优先匹配「命中」的情况；如果写成Contains<TypeList<First, Rest...>, T>放在前面，就会永远匹配，递归无法收敛。

Size用sizeof...(Ts)直接得到参数包长度，不必递归。这是 C++11 可变参数模板带来的便利：很多过去必须递归展开的事情，现在可以一次算完。

SFINAE（substitution failure is not an error，替换失败并非错误）是另一块基石。它的规则是：在模板实参推导和替换过程中，如果某个候选的函数签名替换失败，该候选被移出重载集合，而不是让整个编译失败。std::enable_if就是利用这一点，把「条件不满足」变成「这个重载不存在」。

// 适用于 C++17
#include <type_traits>

template<class T>
constexpr std::enable_if_t<std::is_integral<T>::value, T>
twice(T value) {
return static_cast<T>(value + value);
}

template<class T>
constexpr std::enable_if_t<std::is_floating_point<T>::value, T>
twice(T value) {
return value * static_cast<T>(2);
}

static_assert(twice(21) == 42, "");

两个twice的签名只在返回类型上不同，但因为enable_if_t在条件不满足时会让替换失败，重载集合里始终只剩一个可行候选。注意std::enable_if_t是 C++14 引入的别名模板；C++11 里要写typename std::enable_if<...>::type。

C++20 的 concepts 把这套写法提升为语言特性：约束写在模板参数列表上，错误信息直接指出「哪个约束不满足」，而不是一长串替换失败的候选。需要 C++20 及以上，且各编译器对 concepts 的支持时间不同，使用前应查工具链的支持表。概念不是「新的 SFINAE」，它改变的是约束的表达方式和重载决议的规则，旧代码不必强制迁移。

四、完整示例：编译期筛选类型

下面把类型列表、条件判断和if constexpr组合起来，做一个「从列表中筛出满足条件的类型」的小工具。它不依赖任何第三方库，完整可读。

// 适用于 C++17
#include <cstddef>
#include <type_traits>

template<class... Ts>
struct TypeList {};

// 把满足 Pred 的类型放入 Out
template<template<class> class Pred, class In, class Out>
struct Filter;

template<template<class> class Pred, class Out>
struct Filter<Pred, TypeList<>, Out> {
using type = Out;
};

template<template<class> class Pred, class First, class... Rest, class... Kept>
struct Filter<Pred, TypeList<First, Rest...>, TypeList<Kept...>> {
private:
using next_out = std::conditional_t<
Pred<First>::value,
TypeList<Kept..., First>,
TypeList<Kept...>>;
public:
using type = typename Filter<Pred, TypeList<Rest...>, next_out>::type;
};

template<class T>
using IsInteger = std::is_integral<T>;

using Mixed = TypeList<int, double, char, float, long>;
using OnlyIntegers = typename Filter<IsInteger, Mixed, TypeList<>>::type;

static_assert(std::is_same<OnlyIntegers, TypeList<int, char, long>>::value,
"应当只保留整数类型");

这个实现的关键点有三处。第一，递归的每一步都用std::conditional_t计算「下一轮的输出列表」，再继续处理剩余输入；conditional_t是 C++14 的别名模板。第二，Filter的主模板只声明不定义，两个偏特化分别处理空列表和非空列表，因此不会出现「主模板被误实例化」的情况。第三，Pred是模板模板参数，接受一个「接收类型、提供value」的类模板，std::is_integral正好符合。

std::conditional_t的两个分支类型都必须合法，即使条件为假也会被写出。这里两个分支都是合法的TypeList实例，所以没有问题；如果某个分支依赖「类型 T 必须有某个成员」，就必须改用if constexpr或偏特化延迟实例化，否则会在条件为假时仍然报错。这是模板元编程里最常见的陷阱之一。

常见坑点

• 
  
• ❌ 在依赖上下文中直接写T::type，编译器不认识。✅ 依赖名必须加typename，写成typename T::type；对依赖的成员模板还要加template关键字。
• 
  
• ❌ 模板递归只写递归分支，忘记终止特化。✅ 每个递归都必须有可到达的终止条件；否则会一直实例化到深度上限并报错。
• 
  
• ❌ 用普通if包裹「只对某些类型合法」的代码。✅ 普通if的两个分支都会实例化；改用if constexpr（C++17）或标签分派/偏特化。
• 
  
• ❌ 在头文件里定义非模板函数或全局变量，被多个翻译单元包含后重复定义。✅ 模板本身可以放在头文件；非模板实体用inline（C++17 内联变量）或放在源文件中。
• 
  
• ❌ 认为常量表达式里的有符号溢出和运行时一样是「未定义但可能算对」。✅ 常量求值中的溢出通常直接导致编译失败；不要依赖回绕结果。
• 
  
• ❌ 把std::enable_if写在函数体里而不是签名里。✅ SFINAE 只作用于签名替换；写进返回类型、参数类型或模板参数才有约束效果。
• 
  
• ❌ 为了「零开销」把大量逻辑塞进模板，导致编译时间和目标文件膨胀。✅ 编译期计算换来的运行期收益要具体衡量；复杂逻辑优先用constexpr函数，必要时显式实例化控制膨胀。
• 
  
• ❌ 用模板元编程实现本该由普通函数完成的事情。✅ 运行期数据用运行期代码；模板只处理「类型与结构」这类编译期才能决定的问题。
• 
  

总结

模板元编程的核心不是记住多少技巧，而是理解两条规则：模板实例化发生在编译期，特化决定选择哪条路径。把「值计算」交给constexpr，把「类型选择」交给特化或if constexpr，把「约束」交给enable_if或 concepts，代码会比一堆嵌套技巧清晰得多。现代 C++ 的方向也是让编译期计算更接近普通代码——能用constexpr和if constexpr表达时，就不必再写一长串递归模板。