Concepts 不能彻底替代 SFINAE，二者机制不同：Concepts 在参数替换后、重载解析前检查约束并直接剔除不满足者，错误更清晰；SFINAE 在替换过程中静默丢弃失败特化，仍参与重载解析，适用于动态、异常、元编程等场景。
Concepts 不能“彻底替代” SFINAE，它只是让大部分原本需要 SFINAE 的场景变得更清晰、更安全、更易读；SFINAE 在底层约束失败时仍会参与重载解析，而 Concepts 是在更早的约束检查阶段就排除不满足条件的候选，两者机制不同，目标也不完全重合。
Concepts 和 SFINAE 的触发时机完全不同
Concepts 是在模板参数替换完成之后、重载决议（overload resolution）开始之前进行约束检查；一旦 requires 子句不满足，该模板特化直接被从候选集中移除，不进入重载集。SFINAE 则依赖于“替换失败不是错误”的规则，在模板参数替换过程中，若某表达式（如 decltype(T{}.size())）因类型不支持而无法推导，该特化仅被静默丢弃——但这个过程发生在更底层、更不可控的位置。
这意味着：
- Concepts 错误信息更短、更聚焦于约束本身（比如
"T does not satisfy std::regular"），而 SFINAE 错误常堆叠十几层decltype/std::enable_if展开，难以定位 - Concepts 不会因“意外替换失败”导致重载歧义或隐式转换干扰；SFINAE 容易因过度泛化（如漏写
std::decay_t）让本不该参与重载的模板意外存活 - Concepts 无法表达“仅当某表达式可求值时才启用”的动态条件（例如：只在
T支持operator+且结果可转为int时启用），这种仍需 SFINAE 或requires中嵌套decltype检查
用 requires 替代 enable_if 的典型写法对比
下面是一个判断是否支持 begin()/end() 迭代器访问的函数模板，分别用 SFINAE 和 Concepts 实现：
立即学习“C++免费学习笔记（深入）”；
SFINAE 版本（C++11/14 风格）：
templateauto range_size(const T& t) -> decltype(t.end() - t.begin(), std::size_t{}) { return t.end() - t.begin(); }
Concepts 版本（C++20）：
templaterequires requires(const T& t) { t.begin(); t.end(); } auto range_size(const T& t) { return std::distance(t.begin(), t.end()); }
关键差异点：
-
requires块内是纯表达式检查，不涉及类型推导或decltype嵌套；失败时直接报“Tdoes not satisfy the requires clause” - SFINAE 版本中，
decltype(t.end() - t.begin(), std::size_t{})的逗号表达式容易误写成decltype(t.end() - t.begin())，导致对非随机访问迭代器（如std::list）编译失败而非静默禁用 - Concepts 版本可复用为命名 concept：
template，后续所有函数都能直接写concept range = requires(const T& t) { t.begin(); t.end(); }; range T
Concepts 无法覆盖的 SFINAE 场景
以下情况目前仍需 SFINAE（或 Concepts + SFINAE 混合）：
- 需要根据某个表达式是否“可求值且不抛异常”做重载选择（
noexcept检查），Concepts 的requires不检查异常规范 - 想让一个函数模板对
std::vector启用特化 A，对std::vector启用特化 B，但两者都满足同一 concept；此时必须靠 SFINAE 或部分特化区分 - 实现类似
std::is_convertible_v这类元函数，其本质就是靠 SFINAE 在 sfinae-friendly context 中尝试构造，Concepts 无法替代这种“试探性编译”逻辑
真正要放弃 SFINAE，得先确认你的约束全是静态、正向、类型层面的——比如“支持 operator”“有嵌套 value_type”“可默认构造”。一旦涉及运行时语义、异常、隐式转换路径或元编程探测，SFINAE 或 std::void_t 技巧依然不可绕过。
