requires子句必须紧接模板参数列表右尖括号之后、函数名之前，不可置于函数体、template前或返回类型后；错误位置将导致约束失效。
requires子句必须紧跟模板参数列表之后
写在模板声明里但位置错了，requires 就不生效。它不能放在函数体里、不能放在 template <...></...> 之前，也不能塞到返回类型后——C++20 明确要求它紧接在模板参数列表右尖括号之后、函数名之前。
常见错误是模仿 SFINAE 写法，把约束写成返回类型的一部分，比如：
template <typename t> auto foo(T x) -> std::enable_if_t<:is_integral_v>, int>; // ❌ 不是 concepts </:is_integral_v></typename>
正确写法是：
template <typename t> requires std::integral<t> int foo(T x); // ✅ 约束独立、清晰 </t></typename>
- 多个约束可连写：
requires A<t> && B<t></t></t>或拆成两个requires子句（后者等价于逻辑与） - 如果模板有多个参数，
requires约束的是整个模板，不是某个参数单独受控 - 别在类模板定义体内用
requires声明成员函数约束——得在声明处就写好，否则实例化时可能报错位置反直觉
用 requires 表达式检查表达式有效性最常用
光靠命名概念（如 std::integral）不够灵活，很多场景要验证某个操作是否合法，比如 t + u 是否可调用、container.begin() 是否返回迭代器。这时候就得用 requires 表达式。
它本质是个编译期布尔常量，语法是 { 表达式 } -> 概念 或仅 { 表达式 }（不检查返回类型）：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template <typename t typename u>
requires requires(T t, U u) {
{ t + u } -> std::common_with<t u>;
}
auto add(T t, U u) { return t + u; }
</t></typename>
- 花括号里变量必须先声明（
T t, U u），不能直接写{ a + b } -
-> 概念是可选的，但漏掉可能导致隐式转换绕过检查，比如int + double虽能算，但未必是你想支持的语义 - 表达式里的函数调用不会触发 ADL，除非你在 requires 表达式里显式引入作用域（例如加
using std::swap;）
和 concept 定义混用时注意求值时机
直接在模板里写 requires 子句是“即时求值”，而用 concept 名字（如 requires MyConcept<t></t>）是延迟求值——只有模板被实际实例化且走到该分支时才检查。
这意味着：如果一个 concept 内部用了未定义的类型或非法表达式，它不会在定义时报错，而是在首次匹配失败时才暴露问题；但裸写的 requires 表达式会在模板解析阶段就尝试求值，更容易提前报错。
- 推荐优先定义命名
concept，便于复用和调试，比如concept Addable = requires(T a, T b) { a + b; }; - 避免在
concept定义里调用尚未声明的函数——即使它在后面定义了，concept 检查仍可能失败 - 模板偏特化中用
requires时，约束条件必须互斥，否则可能引发模糊匹配，编译器不一定报错但行为不可靠
requires 不能替代 static_assert，尤其对错误信息友好度差
requires 子句失败时，报错通常只显示“no matching function for call”，不会告诉你哪个约束没满足、为什么没满足。它不像 static_assert 那样能附带自定义提示。
所以当你要明确告诉用户“这个类型必须支持 operatorrequires，补一句 static_assert 更稳妥：
template <typename t>
requires requires(std::ostream& os, T const& t) { os , "T must be printable to std::ostream");
std::cout
<ul>
<li>
<code>requires</code> 控制重载/匹配是否参与，<code>static_assert</code> 控制实例化是否通过，二者定位不同</li>
<li>模板参数推导失败（如函数调用传参不匹配）不会触发 <code>requires</code> 检查，它只在推导成功后才运行</li>
<li>某些编译器（如早期 GCC 10）对嵌套 <code>requires</code> 表达式的错误提示极不友好，遇到奇怪报错先怀疑是不是花括号配对或分号遗漏</li>
</ul>
<font color="gray">真正难的不是写出语法正确的 <code>requires</code>，而是判断该约束是否覆盖了所有必要条件、有没有漏掉隐式转换路径、以及当它和模板推导、ADL、SFINAE 规则叠加时，行为是否符合直觉——这些只能靠小范围实测加编译器输出反复验证。</font></typename>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
