编译期阶乘优先用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++免费学习笔记（深入）”；
《PHP设计模式》首先介绍了设计模式，讲述了设计模式的使用及重要性，并且详细说明了应用设计模式的场合。接下来，本书通过代码示例介绍了许多设计模式。最后，本书通过全面深入的案例分析说明了如何使用设计模式来计划新的应用程序，如何采用PHP语言编写这些模式，以及如何使用书中介绍的设计模式修正和重构已有的代码块。作者采用专业的、便于使用的格式来介绍相关的概念，自学成才的编程人员与经过更多正规培训的编程人员
类型萃取（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) 加注释）比反复改特化条件更有效。
