C++17 最稳写法是 std::void_t + decltype(&T::member) 配合偏特化 trait；C++20 起优先用 requires，但其检测可访问+可求值，非仅声明存在。
直接结论：用 std::void_t + decltype(&T::member) 搭配偏特化 trait 是 C++17 最稳、最兼容的写法；C++20 起优先用 requires，但注意它检测的是可访问+可求值，不是单纯声明存在。
为什么 decltype(&T::member) 必须包在 std::void_t 里
单独写 decltype(&T::member) 会立刻触发硬错误——编译器在模板偏特化匹配前就报 “‘xxx’ is not a member of ‘Y’”，SFINAE 根本没机会生效。只有把它塞进 std::void_t<...></...> 这个“兜底容器”，才能让整个表达式变成一个类型推导上下文，失败时退化为空类型，从而激活 SFINAE。
-
std::void_t<decltype></decltype>合法 → 偏特化版本被选中 -
&T::xxx不存在 →decltype失败 →std::void_t无法实例化 → 主模板（std::false_type）胜出 - 漏掉
std::void_t，哪怕只多一个括号或少一个&，都会让编译器放弃重载选择，直接崩在调用点
std::is_member_object_pointer 比 std::is_same_v 更安全
成员变量可能带 const、volatile、mutable、引用甚至数组修饰，decltype(&T::xxx) 推导出的类型形如 int T::* const volatile。用 std::is_same_v<decltype int t::></decltype> 会因 cv 限定符不匹配而误判为 false；而 std::is_member_object_pointer 只关心“是不是对象指针”，自动忽略修饰符差异。
- 正确写法：
std::is_member_object_pointer<decltype>::value</decltype> - 错误写法：
std::is_same_v<decltype int t::></decltype>（静态断言或 enable_if 中都不可靠） - 若成员是
int&或mutable int，&T::xxx依然合法，trait 仍能识别
函数签名里加约束，std::enable_if_t 放错位置就白写
std::enable_if_t 不是开关，它只在模板参数推导或返回类型解析阶段起作用。放在函数体里（比如 static_assert）或作为普通参数，完全绕过 SFINAE，一出错就是硬错误，不会 fallback 到其他重载。
立即学习“C++免费学习笔记（深入）”；
- ✅ 安全位置一：返回类型 ——
template<typename t> auto foo(T t) -> std::enable_if_t<hasmemberxxx>::value, int>;</hasmemberxxx></typename> - ✅ 安全位置二：默认模板参数 ——
template<typename t typename="std::enable_if_t<HasMemberXxx<T">::value>> void bar(T t);</typename> - ❌ 危险位置：函数体内、非类型模板参数、普通函数参数 —— 都会导致编译失败而非静默屏蔽
C++20 requires 看似简单，但语义不同
requires(T t) { t.xxx; } 检查的是“能否以对象 t 为左值访问并求值 xxx”，这隐含了可访问性（public）、可取值（非 void 类型）、非私有等条件。而 &T::xxx trait 只检查声明是否存在，对友元、私有成员也成立（取决于上下文）。
- 若
xxx是 private 成员，requires版本编译失败，但 trait +enable_if可能通过（尤其在类内调用时） -
requires无法用于类模板部分特化条件，比如template<typename t> struct X<t std::enable_if_t>> {}</t></typename>这种写法，requires插不进去 - 错误信息更友好，但老项目（如 Eigen、Boost）源码里全是 SFINAE，绕不开就得懂
真正容易被忽略的是：成员名是字面量，不能参数化；想支持任意成员名，C++17 得靠宏，C++20 得用 template parameterized concept（需额外封装），不是写个 requires(T t) { t.$name; } 就能行的。
