用 requires 替代 std::enable_if 可将模板错误从数十行嵌套堆栈压缩至1行明确提示，因其在函数签名层即时检查约束，避免SFINAE的深度实例化失败；需精准约束实际使用的操作，合理组合标准concept，并确保包含<concepts>。
直接结论：用 requires 替代 std::enable_if，把约束写在函数签名第一层，错误就能从 50 行嵌套堆栈缩到 1 行明确提示。
为什么传统模板错误让人崩溃
传一个没定义 operator< 的结构体给 std::sort 模板，编译器不会说“你缺比较操作”，而是报一串类似 no type named 'iterator_category' in 'std::__detail::_Iter_cat<...>' 的信息，真正出问题的那行 a < b 藏在第 42 层实例化里。这不是调试，是考古。
根本原因是 SFINAE 是“事后淘汰”机制：编译器先尝试展开所有可能路径，失败了才默默回退——等它报错，已经深陷模板迷宫。
用 requires 把错误拦在调用点
把约束显式写在函数模板参数之后，编译器会在匹配函数签名时就检查，不满足直接拒掉，不往下走任何实例化逻辑。
立即学习“C++免费学习笔记（深入）”；
- 错写成
template<typename T> requires std::equality_comparable<T>—— ✅ 正确，requires是独立子句 - 误写成
template<std::equality_comparable T>—— ❌ 编译失败，这语法禁用类型推导，foo(42)会报no matching function而不是约束失败 - 错误提示对比：
error: constraints not satisfied for 'sort_elements<MyType>': 'MyType' does not satisfy 'equality_comparable'—— 一眼定位
写 requires 表达式时最常踩的坑
不是所有“看起来能用”的操作都该塞进 concept。过度约束会让本可通用的模板变瘸腿。
- 只检查当前函数**真正在用**的操作：比如泛型查找只需
operator==，就别硬塞进Sortable（它要求operator<） - 避免在
requires里调用具体函数，如{ foo(x) }；改用表达式约束：{ x.size() } -> std::same_as<size_t> - 组合约束用
&&/||，别手写一堆std::is_same_v+std::is_invocable_v—— 可读性断崖下跌
标准库 concept 不是银弹，得看头文件和语义
std::integral 看起来安全，但它只检查 std::is_integral_v<T>，不保证支持 + 或可隐式转 int。实际用时仍要按需补约束。
- 需要算术运算？用
std::regular+std::totally_ordered组合，或自定义Addable -
std::copyable检查拷贝构造/赋值，但不检查移动操作 —— 如果函数内部 move 了对象，还得加std::movable - 所有 concept 都来自
<concepts>，漏 include 会报identifier "integral" is undefined
真正难的不是写 constraint，而是判断“这个函数到底依赖类型哪些能力”——少一条，运行时报错；多一条，用户被迫实现无用接口。每次加 requires 前，盯着函数体数三遍它调用了哪些成员、哪些操作符。
