使用concept约束模板参数需定义编译期布尔谓词并置于模板参数列表，如template；检测成员用requires块（如typename T::value_type），组合约束用requires子句或多个concept，避免过度约束与语法错误。
直接用 concept 约束模板参数类型，核心就两点：定义一个编译期布尔谓词，再把它放到模板参数列表里。不满足就报错，而且错误位置准、信息短——不是模板展开几十层后崩在 std::iterator_traits<...>::value_type</...>，而是直接说“T 不满足 Integral”。
怎么写一个基础类型约束的 concept
比如只接受整数类型，别用 std::is_integral_v<t></t> 手动塞进 enable_if 里绕弯子：
必须包含 <concepts></concepts> 头文件；concept 是关键字，后面跟名字和等号右边的常量表达式；标准库已提供 std::integral，直接用就行：
template<:integral t> T add(T a, T b) { return a + b; }</:integral>- 传入
int、long long没问题；传入double或std::string，编译器立刻拒绝，错误信息里会明确写出std::integral未满足 - 不要自己重复造轮子：
template<typename t> concept Integral = std::is_integral_v<t>;</t></typename>虽然语法合法，但语义不如直接用std::integral清晰，且失去标准库未来可能做的优化（比如对__int128的扩展支持）
怎么检查某个成员是否存在（比如 value_type 或 begin()）
不能靠 static_assert 或 SFINAE 在函数体内硬测；要用 requires 块声明“这个东西语法上就得能写出来”：
立即学习“C++免费学习笔记（深入）”；
例如检测嵌套类型 value_type：
template<typename t> concept HasValueType = requires { typename T::value_type; };</typename>
再比如检测容器接口：
template<typename t> concept HasBeginEnd = requires(T&& t) { t.begin(); t.end(); };</typename>
-
typename T::value_type这种写法只验证“能解析”，不求值、不实例化，安全 -
requires(T&& t)中的参数是虚构的，仅用于表达式推导；t.begin()只要求可调用，不要求返回类型具体是什么（若需进一步约束，得加-> std::same_as<...></...>） - 注意：单独检查
begin()不等于支持范围 for 循环；要完整支持for (auto& x : r)，得同时满足begin()、end()和迭代器可解引用，更稳妥的是直接用标准库的std::ranges::range
怎么组合多个约束或做复杂行为检查
单个 concept 表达力有限，常见做法是组合或用内联 requires 子句：
- 组合：比如既要可拷贝又要支持
比较：<code>template<:copyable t> requires std::equality_comparable<t> void sort_helper(T& a, T& b);</t></:copyable> - 内联
requires更灵活：当约束逻辑只用一次、或依赖多个参数时，不必单独命名 concept：template<typename t typename u> auto zip(T&& t, U&& u) requires requires { t.size(); u.size(); } && std::same_as<decltype decltype> { ... }</decltype></typename> - 避免过度约束：比如检查
a + b是否合法时，漏掉返回类型约束会导致std::string + const char*意外满足Addable；正确写法是：{ a + b } -> std::same_as<t></t>
为什么有时候用了 concept 还是报错位置不对
常见原因是约束没覆盖到所有路径。比如函数模板内部调用了另一个模板，而那个模板没加 constraint，或者用了 auto 返回类型却没约束返回值行为。
更隐蔽的问题是 concept 定义本身有误：
- 把
requires { t.begin(); }写成requires { t.begin };（少括号）→ 编译失败，但错误指向 concept 定义处，不是使用者 - 在
requires块里写了运行时才能判断的东西（比如if constexpr分支里的表达式）→ 不合法，requires只接受编译期可判定的表达式 - 自定义 concept 用了未定义行为的表达式（比如对空指针取
decltype(*p)）→ 编译器可能静默忽略或报错不可预测
真正难调试的从来不是“怎么写 concept”，而是“它到底约束了什么、又漏了什么”。建议每次定义完，拿几个明显该过、明显该不过的类型手动试一遍，比看文档管用。
