用 requires 替代 std::enable_if 可将模板错误从数十行嵌套堆栈压缩至1行明确提示，因其在函数签名层即时检查约束，避免sfinae的深度实例化失败；需精准约束实际使用的操作，合理组合标准concept，并确保包含。

直接结论：用 requires 替代 std::enable_if，把约束写在函数签名第一层，错误就能从 50 行嵌套堆栈缩到 1 行明确提示。

为什么传统模板错误让人崩溃

传一个没定义 operator 的结构体给 <code>std::sort 模板，编译器不会说“你缺比较操作”，而是报一串类似 no type named 'iterator_category' in 'std::__detail::_Iter_cat<...>'</...> 的信息，真正出问题的那行 a 藏在第 42 层实例化里。这不是调试，是考古。

根本原因是 SFINAE 是“事后淘汰”机制：编译器先尝试展开所有可能路径，失败了才默默回退——等它报错，已经深陷模板迷宫。

用 requires 把错误拦在调用点

把约束显式写在函数模板参数之后，编译器会在匹配函数签名时就检查，不满足直接拒掉，不往下走任何实例化逻辑。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 错写成 template<typename t> requires std::equality_comparable<t></t></typename> —— ✅ 正确，requires 是独立子句
• 误写成 template<:equality_comparable t></:equality_comparable> —— ❌ 编译失败，这语法禁用类型推导，foo(42) 会报 no matching function 而不是约束失败
• 错误提示对比：error: constraints not satisfied for 'sort_elements<mytype>': 'MyType' does not satisfy 'equality_comparable'</mytype> —— 一眼定位

写 requires 表达式时最常踩的坑

不是所有“看起来能用”的操作都该塞进 concept。过度约束会让本可通用的模板变瘸腿。

• 只检查当前函数**真正在用**的操作：比如泛型查找只需 operator==，就别硬塞进 Sortable（它要求 operator）
• 避免在 requires 里调用具体函数，如 { foo(x) }；改用表达式约束：{ x.size() } -> std::same_as<size_t></size_t>
• 组合约束用 && / ||，别手写一堆 std::is_same_v + std::is_invocable_v —— 可读性断崖下跌

标准库 concept 不是银弹，得看头文件和语义

std::integral 看起来安全，但它只检查 std::is_integral_v<t></t>，不保证支持 + 或可隐式转 int。实际用时仍要按需补约束。

• 需要算术运算？用 std::regular + std::totally_ordered 组合，或自定义 Addable
• std::copyable 检查拷贝构造/赋值，但不检查移动操作 —— 如果函数内部 move 了对象，还得加 std::movable
• 所有 concept 都来自 <concepts></concepts>，漏 include 会报 identifier "integral" is undefined

真正难的不是写 constraint，而是判断“这个函数到底依赖类型哪些能力”——少一条，运行时报错；多一条，用户被迫实现无用接口。每次加 requires 前，盯着函数体数三遍它调用了哪些成员、哪些操作符。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！