std::enable_if用于实现SFINAE，使模板特化在条件不满足时静默退出重载决议；必须置于模板参数或函数返回类型中，不可仅放在函数体内。
std::enable_if 用来干啥？
它不是让模板“禁用”，而是让某个模板特化在条件不满足时直接不参与重载决议——编译器压根看不见它，连错误都不会报。本质是 SFINAE（替换失败不是错误）的工具函数。
常见错误现象：static_assert 或 if constexpr 写在函数体内，结果类型错误还是爆红；或者用了 std::enable_if 却没把它塞进函数签名里，导致编译器无视条件。
- 必须出现在模板参数列表或函数返回类型中（不能只放在函数体里）
- 典型位置：作为默认模板参数、作为返回类型的前置部分、或作为函数参数类型
- C++17 起推荐优先用
std::enable_if_t（更简洁），但底层逻辑完全一样
怎么写一个只接受整数类型的函数模板？
目标：让 foo(3.14) 编译失败，而 foo(42) 正常通过。关键在于把约束“挂”在模板声明上。
template<typename T>
std::enable_if_t<std::is_integral_v<T>, void> foo(T) {
// 只有 T 是整型时，这个函数才存在
}为什么这样写？因为返回类型是 std::enable_if_t<... void></...>，当 T 不是整型时，std::enable_if_t<false void></false> 是未定义类型，触发 SFINAE，该重载被静默丢弃。
立即学习“C++免费学习笔记（深入）”；
- 别写成
void foo(T)+ 函数体内static_assert(std::is_integral_v<t>)</t>：那会报硬错误，破坏重载选择 - 别漏掉
_v后缀：用std::is_integral<t>::value</t>太啰嗦，std::is_integral_v<t></t>是 C++17 引入的便捷变量模板 - 如果想支持返回值，把
void换成你想要的类型，比如std::enable_if_t<... int></...>
为什么 std::enable_if 放参数里也行？
有人这么写：template<typename t> void foo(T, std::enable_if_t<:is_pointer_v>>* = nullptr)</:is_pointer_v></typename>。这不是多此一举，而是为了绕开返回类型限制——比如函数已有明确返回类型，没法再塞 std::enable_if_t 进去。
这种写法靠“添加一个默认为 nullptr 的哑参数”来承载约束，既不影响调用，又能让 SFINAE 生效。
- 参数名可以是任意标识符（比如
= nullptr后面不写名字也合法），但通常留空或叫= nullptr - 不能用
std::enable_if_t<...></...>直接作参数类型（因为可能推导出 void），必须是指针类型，所以常见写法是std::enable_if_t<... int>* = nullptr</...>或直接std::enable_if_t<...>* = nullptr</...>（C++14 起std::enable_if_t<b></b>默认是void，void*合法） - 相比返回类型写法，可读性略差，但灵活性更高，尤其适合成员函数或已有固定返回类型的场景
std::enable_if 在 C++20 里还用得着吗？
能用 requires 约束就别硬套 std::enable_if。比如同样限制整型，template<typename t> requires std::is_integral_v<t> void foo(T)</t></typename> 更直白、错误信息更友好、且支持逻辑组合（&&/||）。
但现实里仍有三个绕不开 std::enable_if 的地方：
- 需要兼容 C++11/14/17 的老项目
- 写 traits 类或元函数时，仍需它配合
typedef或using做类型计算 - 某些高级元编程模式（如 SFINAE-based detection idiom）依赖它做存在性检测，
requires暂不覆盖这类用法
真正容易被忽略的是：即使用了 requires，底层 trait（比如 std::is_integral_v）本身还是靠 std::enable_if 或类似机制实现的——它没消失，只是藏得更深了。
