Concepts 是 C++20 编译期语义约束机制，用于限定模板参数满足特定操作与返回类型要求，提升错误提示位置与可读性，无运行时开销，但需注意定义严谨性、工具链兼容性及跨模块可见性。
Concepts 是 C++20 里用来约束模板参数的语法机制
它不是运行时检查，也不是宏或 SFINAE 的变体，而是在编译期对模板实参做语义层面的契约式限定。你写 template，编译器就真会去查 T 是否满足 Addable 定义的条件——比如有没有 operator+、返回类型是否可赋值、操作数是否能隐式转换等。
怎么定义一个简单 concept（以支持 + 运算为例）
最常用写法是用 requires 表达式列出必要操作，别用 decltype 或 std::is_invocable 手动模拟——那会绕过 concept 的语义清晰性，也失去错误信息优化。
常见错误现象：concept Addable = requires(T a, T b) { a + b; }; 看似简洁，但没约束返回类型，void 或不可赋值类型也能通过；更糟的是，如果 a + b 触发重载解析失败，错误信息反而比不用 concept 还难读。
- 正确做法：显式要求表达式结果可转换为
T或至少可构造：{ a + b } -> std::same_as; - 若允许隐式转换（如
int + double），改用{ a + b } -> std::convertible_to; - 多个操作要并列写在同一个
requires块里，别拆成多个 concept 堆叠——否则约束逻辑变模糊，且编译器不保证短路
为什么 template 参数加了 concept 后报错位置更靠前
因为 concept 检查发生在模板实例化「之前」，属于约束求值阶段；而传统模板错误（比如 T::value 不存在）要等到函数体内部才触发，堆栈深、上下文丢失。
立即学习“C++免费学习笔记（深入）”；
使用场景：当你导出模板接口（如库头文件），或想让使用者一眼看懂「这个函数只接受支持比较的类型」，就该用 concept 替代注释或 static_assert。
-
std::ranges::sort要求迭代器满足random_access_iterator，而不是等进入函数才发现it += n不合法 - 参数差异：带 concept 的模板不能被非匹配类型推导，哪怕有隐式转换——这是有意设计，避免意外降级
- 性能上无开销：concept 不生成额外代码，也不影响 ODR 或内联决策
容易踩的坑：auto + concept 和 constrained placeholder 的区别
写 void f(Addable auto x) 看起来方便，但它等价于 template，每次调用都实例化新函数；而 void f(Addable x)（C++20 允许的 abbreviated template）才是真正的「单个函数签名」，且支持完美转发。
更隐蔽的问题：concept 内部若引用未声明的关联类型（如 T::value_type），而该类型只在部分特化中存在，会导致 constraint unsatisfied，但错误提示可能指向 concept 定义处而非具体实参——这时得配合 static_assert 在 concept 体内加兜底诊断。
兼容性影响：GCC 10+ / Clang 12+ / MSVC 19.28+ 支持完整特性，但老版本只支持部分语法（比如不支持 requires 子句嵌套）。上线前务必确认工具链版本。
真正麻烦的是跨模块 concept 可见性：如果 A 模块定义了 MyConcept，B 模块用了它但没包含对应头文件，错误不会说「concept 未定义」，而是报「约束不满足」——因为编译器根本没见过这个符号。这种问题只在链接期或模块导入时才暴露，调试成本高。
