std::concepts 不能用 typename t 替代，因为后者不检查约束，错误延迟到模板实例化深处；而 concepts 将约束前置到声明处，使错误出现在调用点且提示明确。
std::concepts 为什么不能直接用 typename T 替代？
因为 typename T 完全不检查 T 能不能用——比如你写了个要求支持 operator+ 的加法函数，传入 std::string 没问题，但传入 std::vector<int></int> 就编译失败，错误信息还藏在模板展开深处。而 std::concepts 把约束提前到模板声明处，让错误出现在调用点，且提示明确。
关键不是“能不能写”，而是“错得清不清楚”。没概念时，错误常类似：no match for 'operator+' (operand types are 'std::vector<int>' and 'std::vector<int>')</int></int>；加了概念后，直接报：constraints not satisfied for 'addable<:vector>>'</:vector>。
怎么定义一个最简可用的 concept？
用 concept 关键字 + requires 表达式，核心是描述“T 必须能做什么”，不是“T 是什么类型”。
- 必须写在命名空间作用域（不能在函数内）
-
requires块里写的是合法 C++ 表达式，编译器会尝试代入 T 去验证是否能通过 SFINAE - 别写运行期逻辑（比如
if或变量定义），只写表达式或类型约束
例如约束“可加”：
template<typename t>
concept addable = requires(T a, T b) {
a + b;
};</typename>
注意：这里 a + b 不求值，只检查语法和重载是否存在；T 会被实际类型替换后验证。
如何在函数模板中使用 concept 约束参数？
有两种等效写法，推荐后者——更清晰、更易读、支持重载解析。
- 约束模板参数列表：
template<addable t> T sum(T a, T b) { return a + b; }</addable> - 约束函数声明：
addable auto sum(addable auto a, addable auto b) { return a + b; }
区别在于：前者仍需显式写 template<...></...>，后者是 C++20 的简写形式，自动推导模板参数并应用约束。但注意 auto 版本无法偏特化，且多个参数类型不同时要分开写：addable auto a, multiplyable auto b。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
如果函数有多个参数且需不同约束，别偷懒合并——比如加法和乘法混合运算，应分别约束：template<addable a multiplyable m> auto compute(A a, M m)</addable>。
常见坑：std::regular、std::equality_comparable 这些标准 concept 为什么有时不生效？
因为它们只检查接口契约，不保证语义正确。比如 std::equality_comparable 只要求 a == b 有效，但如果你的 operator== 总返回 false，它照样满足概念——概念管不了逻辑 bug。
另一个高频陷阱是自定义类型忘了声明关联类型。例如实现 std::iterator 时，若没提供 value_type、reference 等 typedef，哪怕操作符都全了，std::input_iterator 也会失败。
调试方法：用 static_assert 显式触发检查：
static_assert(addable<mytype>); // 编译失败时会指出哪条 requires 不满足</mytype>
比依赖函数调用失败更早暴露问题。
真正难的不是写 concept，而是想清楚你要约束的是“语法能力”还是“语义契约”——前者靠编译器验证，后者得靠文档和测试兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
