编译期阶乘优先用constexpr函数，直观、可读性强且支持运行时回退；仅当需类型层面计算（如生成不同大小数组）或C++11以前环境时才用模板递归。
编译期阶乘怎么写，constexpr 和模板递归选哪个？
C++11 起，constexpr 函数就能做编译期阶乘，比模板元编程（TMP）直观得多。但如果你用的是 C++11 以前的环境，或者想在类型层面做计算（比如生成不同大小的数组），才真需要模板递归。
-
constexpr阶乘：函数体简单、可读性强、支持运行时回退（参数不满足常量表达式时自动转成普通函数调用） - 模板递归阶乘：必须全在类型系统里完成，
value是静态成员，无法直接参与运行时逻辑，且错误信息更晦涩
template<int N>
struct factorial {
static constexpr int value = N * factorial<N-1>::value;
};
template<>
struct factorial<0> {
static constexpr int value = 1;
};
// 用法：factorial<5>::value → 编译期得 120
注意：C++17 后 constexpr if 让 constexpr 函数能处理分支逻辑，进一步削弱了纯 TMP 的必要性。
std::enable_if 为什么总报错“no type named 'type'”？
这是最常卡住新手的地方——std::enable_if 默认不定义 type，只在条件为 true 时才注入。一旦你写的条件是 false，编译器就找不到 type，报错直指这一行。
- 常见误写：
typename std::enable_if<cond>::type</cond>—— 缺少默认值，Cond为假时整个模板参数列表非法 - 正确写法要补上默认类型（通常是
void）：typename std::enable_if<cond void>::type</cond> - 更现代的写法（C++14 起）：
std::enable_if_t<cond></cond>，本质就是typename std::enable_if<cond>::type</cond>的别名，但更短、更安全
别忘了它通常用在函数模板参数或类模板参数的默认值位置，不是随便塞哪儿都行。用错位置会导致 SFINAE 失效，变成硬错误。
立即学习“C++免费学习笔记（深入）”；
类型萃取（type traits）怎么避免重复造轮子？
自己写 is_pointer 或 remove_cv 完全没必要。标准库的 <type_traits></type_traits> 已覆盖绝大多数需求，而且经过严格测试和编译器深度优化。
- 所有标准 trait 都是
constexpr、noexcept，且多数在编译期零开销 - 注意区分后缀：
_v（如std::is_pointer_v<t></t>）是 C++17 引入的变量模板，返回bool；而::value在 C++17 前是唯一方式 - 自定义 trait 如果只是组合已有 trait，优先用
std::integral_constant或直接 alias：template<class t> using is_integral_or_enum = std::disjunction<:is_integral>, std::is_enum<t>>;</t></:is_integral></class>
手写 trait 最容易踩的坑是没处理引用折叠、cv 限定符传播、或未考虑 void 等特殊类型，标准实现已经把这些边界 case 全兜住了。
模板元编程代码变慢、报错难读，问题出在哪？
TMP 不会拖慢运行时，但会显著拉长编译时间，尤其嵌套深、实例化多的时候。错误信息爆炸的根本原因是：每个模板实例化都会展开一层，编译器报错时往往显示最后一层失败，但根因可能在上游某次特化里。
- 避免深层递归：比如用
factorial，某些编译器会爆模板递归深度（GCC 默认 900，Clang 256），可用-ftemplate-depth=调，但治标不治本 - 用别名模板替代嵌套：把
typename T::type::inner::value_type拆成中间using，让错误定位更准 - C++17 的
if constexpr是降维打击：能把原本需要模板特化的分支逻辑，收进一个函数里，大幅减少实例化数量和错误噪音
真正难调试的从来不是“算不对”，而是“根本没走到你想让它走的特化分支”——这时候检查 static_assert + 类型打印（比如 decltype(x) 加注释）比反复改特化条件更有效。
