std::enable_if放返回类型最安全，因其属于函数签名，在替换阶段触发SFINAE而被静默剔除；若放函数体内则属实例化阶段，直接报错。
它不是“模板错了就忽略”，而是编译器在**替换阶段**发现某个模板候选因类型不匹配而无法生成合法签名时，默默把它从重载候选集中剔除——仅此而已。其他所有阶段的错误，该报错还是报错。
为什么 enable_if 放返回值位置最安全
因为返回类型属于函数签名的一部分，在模板参数推导和替换阶段就被检查；放在这里的 enable_if 失败会触发 SFINAE，不会导致硬错误。
-
std::enable_if_t<:is_integral_v>, int></:is_integral_v>在 T 不是整型时，整个返回类型变成非法（enable_if<false int>::type</false>不存在），但这是替换失败，编译器跳过该重载 - 如果把
enable_if放进函数体里（比如static_assert或直接调用不存在的成员），那就属于实例化阶段，直接报错，SFINAE 不生效 - 参数列表里也能用（如
typename = std::enable_if_t<...></...>），但要注意默认模板参数的替换时机和重载决议顺序，稍不注意就和另一个重载冲突
decltype + declval 探测表达式是否合法
这是最常用、也最容易写错的 SFINAE 场景。核心是让编译器“假装”调用某个表达式，只看签名是否成立，不执行也不检查函数体。
- 写法必须是
decltype(std::declval<t>().begin())</t>，不能漏掉std::declval<t>()</t>—— 它生成一个无定义但类型正确的右值引用，避免构造开销和副作用 - 如果写成
decltype(T().begin())，某些类型（如抽象类、无默认构造函数的类）会在替换阶段就因构造失败而报错，这不是 SFINAE 范围，而是硬错误 - 探测多个成员时，逗号表达式可以串连：
decltype(std::declval<t>().begin(), std::declval<t>().end(), std::true_type{})</t></t>
常见误判：不是所有“没报错”都是 SFINAE 在起作用
很多开发者看到“找不到匹配函数”就以为是 SFINAE 筛选掉了所有候选，其实更可能是根本没进替换阶段，或者失败发生在别处。
立即学习“C++免费学习笔记（深入）”；
-
error: no type named 'type' in 'struct std::enable_if<false>'</false>—— 这说明enable_if的条件为 false，且你把它用在了非替换上下文（比如类模板偏特化里没加第二参数兜底），这不是 SFINAE，是硬错误 - 调用私有成员、访问受限基类、违反
constexpr约束等，都属于实例化阶段语义检查，SFINAE 拦不住 - 类模板的 SFINAE 行为比函数模板更受限：主模板替换失败是硬错误；只有偏特化或全特化中的替换失败才可能被静默丢弃
真正难的从来不是写出能编译的 SFINAE 代码，而是当重载不按预期走时，能快速判断问题出在替换阶段（可修复）、实例化阶段（必须改逻辑）、还是根本没进模板推导（实参类型不对或重载优先级被干扰）。
