std::integral_constant比手写递归模板更可靠，因其采用迭代式偏特化或内置机制规避模板实例化深度限制，而手动递归易触发编译器深度超限错误。
C++ 模板元编程不是“运行时编程的编译期翻版”，它本质是利用模板实例化规则做纯编译期计算，所有结果必须在 constexpr 上下文或类型系统中固化。
为什么 std::integral_constant 比手写递归模板更可靠
手动展开 factorial::value 看似直观，但一旦嵌套过深（比如 factorial），多数编译器会因模板递归深度超限报错：error: template instantiation depth exceeds maximum。而 std::integral_constant 是标准库特化实现，通常用迭代式偏特化或内置机制规避深度问题。
- 优先用
std::integral_constant<int>::value</int>替代自定义struct factorial { static constexpr int value = ... }; - 若需自定义逻辑，改用
constexpr函数（C++14 起支持循环），比模板递归更易读、更少触发深度限制 - 注意：
std::integral_constant的value是static constexpr成员，可直接用于非类型模板参数，如std::array<int std::integral_constant>::value></int>
constexpr if 在 C++17 中如何替代 SFINAE 做编译期分支
以前用 enable_if + 重载实现类型分发，代码冗长且错误信息难读；constexpr if 把分支逻辑拉回函数体内，编译器只实例化满足条件的分支，未选中分支不参与语义检查。
- 必须在
constexpr函数内使用，且条件表达式必须是编译期常量（如std::is_same_v<t int></t>） - 未被选中的分支里即使写了非法代码（比如对非浮点类型调用
std::sqrt），只要不实例化就不会报错 - 注意：
constexpr if不改变作用域——两个分支里的变量名若重复，会导致编译错误，哪怕它们永不共存
template<typename T>
constexpr auto get_value(T t) {
if constexpr (std::is_floating_point_v<T>) {
return t * 2.0;
} else {
return t * 2;
}
}模板参数推导失败时，decltype 和 std::declval 怎么配合用
想在编译期获取某个表达式的类型（比如 foo(x).bar() 的返回类型），但 x 无法构造或 foo 是私有函数——这时不能直接写 decltype(foo(x).bar())，因为 x 未定义。
立即学习“C++免费学习笔记（深入）”；
- 用
std::declval<t>()</t>构造一个假想的右值引用，仅用于类型推导，不产生实际对象 - 组合写法：
decltype(foo(std::declval<x>()).bar())</x>，其中X是你期望的参数类型 - 常见坑：
std::declval不能出现在普通函数体中（只允许在未求值上下文），所以必须放在decltype、sizeof、模板参数默认值等位置 - 替代方案：C++20 起可用
requires表达式做更清晰的约束，但类型提取仍依赖decltype+declval
真正卡住人的往往不是语法，而是误以为“模板能算一切”——比如试图在模板中做字符串拼接或遍历容器。这些操作在标准 C++ 中要么不可行，要么要靠 C++20 的 consteval 或第三方库（如 Boost.MP11）补足。编译期计算的边界，得看标准怎么画，不是看想法多大胆。
