requires 是编译期约束守门人，负责模板实例化初期筛选合法类型；if constexpr 是函数体内条件开关，对已满足约束的类型做细化分支。二者阶段不同、分工明确，不可互替。
requires 子句负责编译期约束，if constexpr 负责分支内细化逻辑
requires 是模板声明层面的“守门人”，它在模板实例化初期就检查概念是否满足；而 if constexpr 是函数体内的“条件开关”，只对已通过 requires 的类型做进一步分支判断。二者不在同一阶段工作，不能互相替代，但能形成清晰分工：前者筛掉非法类型，后者在合法类型中按细节做差异化实现。
典型组合写法：先用 requires 过滤，再用 if constexpr 分支
常见错误是试图在 requires 中写复杂逻辑（比如调用未定义的 SFINAE 表达式），或在 if constexpr 中处理本该由 requires 拦截的非法类型（导致硬错误）。正确做法是：
-
requires只依赖已定义的概念（如std::integral、自定义Sortable）或简单表达式（如T::value是否可访问） -
if constexpr内部可安全使用decltype、sizeof、成员检测等，因为此时T已确定满足约束 - 若需多级分类（比如先分整型/浮点，再分有符号/无符号），
requires做第一层粗筛，if constexpr做第二层细判
template<typename T>
requires std::integral<T> || std::floating_point<T>
T normalize(T x) {
if constexpr (std::floating_point<T>) {
return x < 0 ? -x : x; // fabs 不必要，且 float/double 行为一致
} else {
return x < 0 ? -x : x; // 对 signed int 安全；unsigned 不会进此分支（被 requires 拦住）
}
}
requires 失败时 if constexpr 不会被解析，但反之不成立
这是关键行为差异：requires 检查失败 → 整个模板不参与重载决议 → 函数体（含 if constexpr）根本不会被实例化；而 if constexpr 分支里若写了非法代码（比如对 T 调用不存在的 .size()），只要该分支未被选中，就不会报错 —— 但前提是该模板本身已通过 requires 或其他约束进入候选集。
- 错误示例：给
std::string类型调用normalize<std::string>→requires失败 → 编译器直接忽略该特化，连if constexpr都不看 - 危险示例：删掉
requires，仅靠if constexpr (has_size_v<T>)分支 → 若传入int，else分支里若误写t.size()就会触发硬错误 - 所以
requires是兜底，if constexpr是优化，顺序不能颠倒
性能与可读性权衡：别把所有判断都塞进 if constexpr
过度依赖 if constexpr 会让单个函数体膨胀，尤其当分支逻辑复杂时。更清晰的做法是用 requires 拆成多个约束更精确的函数重载：
立即学习“C++免费学习笔记（深入）”；
template<typename T>
requires std::signed_integral<T>
T abs_impl(T x) { return x < 0 ? -x : x; }
template<typename T>
requires std::unsigned_integral<T>
T abs_impl(T x) { return x; } // 无符号类型无需计算
template<typename T>
requires std::floating_point<T>
T abs_impl(T x) { return std::abs(x); }
这种写法比一个带三层 if constexpr 的函数更易维护，编译器生成的代码也更干净。只有当分支逻辑高度相似、仅差一两个操作时，才值得用 if constexpr 合并。
真正容易被忽略的是：requires 约束一旦写错（比如漏掉 const 限定或引用类别），会导致重载决议意外失败；而 if constexpr 的条件表达式若依赖 ADL 或未完全定义的 trait，可能在某些编译器上表现不一致。务必用 static_assert 在函数体内补一手验证。
