前言
「判断某个类型有没有名为foo的成员函数」是泛型编程里的常见需求：容器适配器想知道元素类型是否可哈希，序列化框架想知道类型有没有serialize成员，包装类想在「有成员函数就调用、没有就走默认路径」之间做分派。C++11 没有concepts，也没有requires，能做到这件事的只有 SFINAE（substitution failure is not an error，替换失败并非错误）配合decltype。
典型误解是把这当成「运行期反射」。C++ 没有运行期反射，这类检测全部发生在编译期：编译器尝试对某个表达式做替换，如果替换失败，就把这个候选从重载集中移除，而不是报错。检测的结果是一个编译期常量，通常以std::true_type/std::false_type的形式暴露，可以用于if constexpr（C++17）或标签分派（tag dispatch）。
另一个常见误区是直接写decltype(&T::foo)来判断。这对无重载、无模板的普通成员函数可行，但一旦成员函数有重载、是模板、或是继承来的，取地址就会产生歧义或失败，得到错误的结论。稳妥的做法是检测「调用表达式是否合法」，而不是检测「成员名字是否存在」。
本文给出 C++11 可用的两种写法，再说明 C++17 的std::void_t如何简化代码，最后提一下 C++20 的requires表达式。所有代码以 C++17 为基准，标注了需要更低或更高标准的段落。
一、SFINAE 与decltype的基本配合
先看一个最小的检测器：判断类型T是否有无参成员函数foo()。
// 适用于 C++11 及以上
#include <type_traits>
#include <utility>
// C++11 没有 std::void_t，自己做一个
template <typename...>
struct make_void {
using type = void;
};
template <typename... Ts>
using void_t = typename make_void<Ts...>::type;
template <typename T, typename = void>
struct has_foo : std::false_type {};
template <typename T>
struct has_foo<T, void_t<decltype(std::declval<T&>().foo())>> : std::true_type {};逐行解释。主模板has_foo<T, void>有两个参数，第二个默认是void，继承std::false_type，表示「默认没有」。偏特化版本把第二个参数写成void_t<...>，只有当尖括号里的表达式合法时，void_t才会被替换成void，偏特化才能匹配。
decltype(std::declval<T&>().foo())是关键。std::declval<T&>()返回T&类型的右值引用表达式，它只出现在不求值的语境中（decltype的操作数不被求值），因此不需要T可默认构造，也不会真的调用任何函数。整个表达式的类型是foo()的返回类型，只要这次调用在语法和重载决议上成立，decltype就能得到一个合法类型。
如果T没有foo，或者foo需要参数，替换失败。按照 SFINAE 规则，这个偏特化被静默丢弃，编译器回退到主模板，has_foo<T>::value为false。整个过程不产生编译错误。
使用时：
// 适用于 C++17
#include <iostream>
struct WithFoo {
void foo() {}
};
struct WithoutFoo {
void bar() {}
};
int main() {
static_assert(has_foo<WithFoo>::value, "WithFoo should have foo");
static_assert(!has_foo<WithoutFoo>::value, "WithoutFoo should not have foo");
std::cout << has_foo<WithFoo>::value << has_foo<WithoutFoo>::value << "\n";
return 0;
}static_assert在编译期求值，如果结论与预期不符，编译直接失败。这比运行期打印可靠得多，建议在库代码里用它把假设固定下来。
二、带参数与 const 限定的成员函数
真实场景里，成员函数通常带参数，而且是否 const 会影响能否在 const 对象上调用。检测表达式要如实反映调用方式。
// 适用于 C++11 及以上
#include <type_traits>
#include <utility>
template <typename T, typename Archive, typename = void>
struct has_serialize : std::false_type {};
template <typename T, typename Archive>
struct has_serialize<
T,
Archive,
void_t<decltype(std::declval<const T&>().serialize(std::declval<Archive&>()))>
> : std::true_type {};这里用const T&调用，意味着只有「const 成员函数」或「按值/const 引用接收的普通函数」才能通过。如果某个类型只提供了非 const 版本的serialize，检测结果就是false——这正是我们想要的，因为序列化通常不应该修改对象。
如果想同时接受 const 与非 const 版本，可以写两个检测器，或者用std::declval<T&>()放宽要求。要清楚的是，检测的是「这个表达式能否成立」，不是「这个名字是否存在」。同一个类可以有serialize(int)而没有serialize(Archive&)，检测结果依然为假，这是特性而非缺陷。
参数类型用模板参数Archive传入，而不是写死某个具体类型，这样检测器可以复用于不同的归档格式。std::declval<Archive&>()同样只在decltype中求值，不要求Archive可构造。
三、不用void_t的经典写法
std::void_t是 C++17 才进入标准的（定义在<type_traits>）。如果项目必须兼容 C++11，除了上面自定义的版本，还有一种更老但完全不依赖别名模板的写法，用重载决议和sizeof的技巧：
// 适用于 C++11 及以上
#include <type_traits>
#include <utility>
template <typename T>
class has_begin {
private:
template <typename U>
static auto test(int)
-> decltype(std::declval<U&>().begin(), std::true_type{});
template <typename>
static std::false_type test(...);
public:
static constexpr bool value = decltype(test<T>(0))::value;
};这个写法的核心是重载优先级：test(int)比test(...)更匹配，所以只要test(int)的返回类型替换成功，就会选它；替换失败时它被移除，回退到接受任意参数的test(...)，返回std::false_type。
decltype里的逗号表达式(expr, std::true_type{})先计算左边（不真正求值，只是检查合法性），整个表达式的类型取右边，即std::true_type。这是「只要左边合法就返回真」的常用技巧。
static constexpr bool value在类内定义，C++17 起constexpr静态数据成员隐含inline，不需要类外再定义；C++11/14 如果在运行期 ODR-use 它（例如取地址），仍需在类外提供定义。检测器通常只在编译期使用，不会触发 ODR-use，但这一点在写库时要心里有数。
四、C++17 与 C++20 的简化
C++17 把void_t收进标准库，上面的自定义版本可以删掉，直接#include <type_traits>使用std::void_t。这让检测器的样板代码缩短到十行左右。
需要提醒的是，标准库没有在 C++17 中提供std::is_detected。它出现在 Library Fundamentals TS v2 里，头文件是<experimental/type_traits>，命名空间是std::experimental，是否可用取决于编译器与标准库版本。不要把它当成 C++17 的正式设施。
C++20 引入了requires表达式，同样的检测可以写成概念（concept）：
// 需要 C++20 及以上
#include <concepts>
#include <iostream>
template <typename T>
concept HasFoo = requires(T t) {
t.foo();
};
struct WithFoo { void foo() {} };
struct WithoutFoo { void bar() {} };
int main() {
static_assert(HasFoo<WithFoo>);
static_assert(!HasFoo<WithoutFoo>);
return 0;
}requires(T t) { t.foo(); }检查的是「给定一个T类型的表达式，t.foo()是否良构」。注意这里t是形参，requires表达式不会真正调用它，只做语法检查。相比 SFINAE，概念的错误信息可读性更好，而且可以直接用于约束模板参数，让重载决议更清晰。
C++20 的编译器支持已经比较普遍，但concepts在一些较老的编译器版本上、或需要特定编译选项时可能不可用，实际项目要按工具链的支持表决定。
五、检测到之后做什么
检测本身只是手段，真正的价值在于「按检测结果选择实现」。C++17 起最直接的写法是if constexpr：
// 适用于 C++17
#include <iostream>
#include <type_traits>
#include <utility>
template <typename T>
void dump(const T& value) {
if constexpr (has_serialize<T, std::ostream>::value) {
value.serialize(std::cout);
} else {
std::cout << value;
}
}if constexpr在编译期丢弃不满足条件的分支，因此即使T没有serialize，value.serialize(std::cout)也不会被实例化，不会报错。这是它相对普通if的关键差异：普通if的两个分支都会被编译。
在 C++11/14 里没有if constexpr，需要用标签分派：写两个重载函数，一个接收std::true_type，一个接收std::false_type，再把has_serialize<...>{}作为额外实参传进去。这种写法代码量大，但完全符合 C++11。
常见坑点
坑点一：用&T::foo判断，遇到重载就失败。
// ❌ 错误：foo 有重载时取地址有歧义，检测结果不可靠
template <typename T, typename = void>
struct has_foo : std::false_type {};
template <typename T>
struct has_foo<T, void_t<decltype(&T::foo)>> : std::true_type {};// ✅ 正确：检测调用表达式，而不是成员指针
template <typename T>
struct has_foo<T, void_t<decltype(std::declval<T&>().foo())>> : std::true_type {};坑点二：在decltype之外调用std::declval。
// ❌ 错误：declval 只有声明没有定义，运行期调用是链接错误
auto v = std::declval<T>();// ✅ 正确：只放在 decltype 或 requires 等不求值语境
using R = decltype(std::declval<T>().foo());坑点三：检测时用了非 const 对象，却指望能检测 const 成员。
// ❌ 错误：非 const 调用无法区分成员函数是否 const 限定
decltype(std::declval<T&>().foo())// ✅ 正确：需要 const 语义时显式用 const 引用
decltype(std::declval<const T&>().foo())坑点四：把检测结果当作运行期布尔值。
// ❌ 错误：has_foo<T>::value 是编译期常量，不能用于运行期分支决定类型
if (has_foo<T>::value) { T::foo(); }// ✅ 正确：用 if constexpr（C++17）或标签分派
if constexpr (has_foo<T>::value) { value.foo(); }坑点五：以为std::is_detected是 C++17 标准设施。
// ❌ 错误：直接写 std::is_detected，多数标准库的 C++17 模式里不存在
static_assert(std::is_detected<has_foo, T>::value);// ✅ 正确：用 std::void_t 自己写，或使用 std::experimental 版本
static_assert(has_foo<T>::value);坑点六：检测私有成员函数。
// ❌ 错误：访问控制失败也会让替换失败，得到 false，但不代表「没有」
class X { private: void foo(); };// ✅ 正确：检测器只能看到可访问的成员，私有成员应通过公开接口暴露坑点七：忘记#include <utility>。
// ❌ 错误：std::declval 声明在 <utility> 中
#include <type_traits>// ✅ 正确：同时包含两个头文件
#include <type_traits>
#include <utility>总结
| 方案 | 标准 | 特点 |
|---|
自定义void_t+ 偏特化 | C++11 | 兼容性最好，样板略多 |
std::void_t+ 偏特化 | C++17 | 代码最短，推荐 |
重载test(int)/test(...) | C++11 | 不依赖别名模板，适合老代码 |
requires表达式 | C++20 | 错误信息清晰，可直接约束模板 |
检测成员函数存在的本质，是把「这个表达式是否良构」变成一个编译期布尔值。SFINAE 提供了「替换失败不报错」的机制，decltype提供了「只看类型不求值」的能力，两者结合就是 C++11 时代的检测惯用法。到了 C++20，requires把这套技巧包装成了语言特性，思路并没有变。
