C++20 Concepts是目前唯一能静态约束“模板参数必须有某成员变量”的标准方案，因其通过requires表达式在编译期早期检查公有成员存在性与类型，错误明确、可读性强；而static_assert无法用于此场景，因它在实例化后求值且不支持SFINAE，遇未定义成员直接硬报错；C++17及以前只能依赖冗长晦涩的SFINAE trait，缺乏语义清晰度与组合能力。
直接说结论：C++20 的 concepts 是目前唯一能静态约束“模板参数必须有某成员变量”的标准方案；C++17 及以前只能靠编译错误倒推，或用 SFINAE 手写 trait，但可读性差、报错晦涩。
为什么不能直接用 static_assert 检查成员变量？
你可能会写这样的代码：
template <typename T>
void process(T& obj) {
static_assert(obj.has_flag, "T must have member 'has_flag'");
// ...
}这会失败——static_assert 在实例化时求值，但 obj.has_flag 是运行时表达式，且未定义时直接导致硬错误（不是 SFINAE 友好），编译器根本不会进入函数体就报错，更谈不上“约束”。
真正可行的路径是：在模板参数推导/实例化早期，用类型层面的属性做判断。这正是 concepts 的设计目标。
立即学习“C++免费学习笔记（深入）”；
requires 表达式检查成员变量是否存在
最轻量、最常用的方式是用 requires 表达式验证嵌套成员：
- 检查公共成员变量：
requires std::is_same_v<decltype bool></decltype>不够安全，因为t.flag可能是私有或不存在；应改用requires requires (T t) { t.flag; } - 检查成员变量类型（比如必须是
int）：requires requires (T t) { { t.count } -> std::same_as<int>; } - 检查是否可读可写：
requires requires (T t) { t.value = 42; { t.value } -> std::convertible_to<int>; }
注意：所有这些都作用于类型 T 的**对象表达式**，不触发实际构造或访问，纯编译期元编程。
定义可复用的 concept：比如 HasIdMember
把常见约束封装成命名 concept，提升可读性和复用性：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template <typename T>
concept HasIdMember = requires(T t) {
t.id;
};然后在函数模板中直接使用：
template <HasIdMember T>
void log_id(const T& obj) {
std::cout << "id = " << obj.id << '\n';
}调用时若传入没有 id 成员的类型，错误信息会明确提示：constraint failure: HasIdMember<MyStruct> is not satisfied，而不是一长串模板展开堆栈。
几个关键点：
- concept 定义本身不生成代码，只用于约束；
- 不能在 concept 中写逻辑判断（如
if (t.id > 0)），它只检查“能否写出该表达式”； - 如果成员是私有的，
requires (T t) { t.id; }仍会失败——C++ 的访问控制在约束检查阶段同样生效。
兼容旧标准：C++17 怎么近似实现？
没有 concepts 时，主流做法是手写 trait + std::enable_if_t：
template <typename T, typename = void>
struct has_member_flag : std::false_type {};
<p>template <typename T>
struct has_member_flag<T, std::void_t<decltype(std::declval<T>().flag)>>
: std::true_type {};</p><p>template <typename T>
std::enable_if_t<has_member_flag<T>::value>
process(T& obj) { /<em> ... </em>/ }问题在于：
- trait 写法冗长，每个新成员都要复制粘贴模板；
- 错误信息仍是“no type named ‘type’ in std::enable_if_t<false>”，毫无上下文；
- 无法约束多个条件组合（比如“有 id 且 id 是整型且可赋值”），逻辑爆炸。
所以除非项目卡在 C++17 且无法升级，否则别走这条路。
真正容易被忽略的是：concept 约束只对**公有可访问成员**有效，且不检查 const/volatile 限定符匹配；如果你依赖私有成员或需要精确类型语义（比如 const int& 而非 int），就得配合 { t.member } -> std::same_as<const int&> 这类更精细的 requires 子句——漏掉这点，约束就形同虚设。
