Concepts 能提前发现模板错误，如 std::sort 对迭代器类型约束不满足时立即报错而非展开大量晦涩错误；自定义 Concept 应描述操作可行性而非贴标签，用 requires 块检查表达式合法性与返回类型；约束位置影响语义：模板参数级最清晰，函数尾部用于 SFINAE，if constexpr 用于编译期分支；Concepts 不提升运行时性能，但增强泛型安全性与接口契约明确性。
Concepts 能帮你提前发现模板错误
没有 Concepts 时，std::sort 接收一个随机访问迭代器，但如果你传入 std::list<int>::iterator</int>（只支持双向遍历），编译器不会在第一眼报错，而是深入到内部实现里展开大量模板实例化后才爆出几十行晦涩的错误信息。用 Concepts 后，约束写在函数声明处：
template<std::random_access_iterator Iter> void my_sort(Iter first, Iter last);——传错类型立刻提示“
std::list<int>::iterator</int> does not satisfy std::random_access_iterator”，错误位置精准、信息直白。
自定义 Concept 要写清楚“它必须能做什么”
Concept 不是给类型贴标签，而是描述一组操作是否可用。比如想约束某个类型支持加法和取负：
template<typename T>
concept AddableAndNegatable =
requires(T a, T b) {
{ a + b } -> std::same_as<T>;
{ -a } -> std::same_as<T>;
};注意三点：
- 用
requires块列出表达式，不是检查成员名 -
{ a + b }表示“这个表达式合法”，-> std::same_as<t></t>才检查返回类型 - 不要写
requires std::is_arithmetic_v<t></t>这类静态断言——Concept 的意义在于约束接口行为，不是硬塞类型列表
Concept 约束位置不同，语义完全不同
同一个 Concept 放在不同地方，效果差很远：
- 作为模板参数约束：
template<addableandnegatable t></addableandnegatable>→ 编译期筛选，不匹配直接不参与重载解析 - 放在函数声明末尾：
void f(T t) requires AddableAndNegatable<t>;</t>→ 属于 SFINAE 友好约束，失败时该重载被静默丢弃 - 用在
if constexpr里：if constexpr (AddableAndNegatable<t>)</t>→ 运行时不可见的编译期分支，适合写 fallback 逻辑
别指望 Concepts 提高性能，但它让泛型更安全
Concepts 本身不改变生成代码，也不影响运行时开销。它的价值全在编译期：
- 避免无意中实例化不支持的操作（比如对
std::vector<bool></bool>调用data()） - 让库作者能明确写出“这个算法要求什么”，而不是靠文档或用户试错
- 配合
std::ranges等新设施，才能真正启用基于范围的、可组合的算法
