requires无法检测私有成员，因为访问私有成员是硬错误而非sfinae友好约束失败；唯一可行方式是类型自身提供公有静态探测接口，否则应约束公有契约而非私有实现。
不能用 requires(T t) { t.private_member; } 直接检查私有成员——编译器会因访问权限拒绝，这不是约束失败，而是硬错误。
为什么 requires 无法检测私有成员
requires 表达式中的 t.private_member 要求该表达式在当前上下文可合法求值。私有成员在模板定义处不可见，编译器直接报 error: 'private_member' is inaccessible，SFINAE 不触发，错误堆栈深、定位难。
- 它不是“类型是否存在”的探测，而是“我能不能写这行代码”的语法+语义检查
- 即使类把模板声明为
friend，requires也无法利用该友元关系——友元只对函数体生效，不延伸至约束求值阶段 - 想靠
requires检私有成员，唯一办法是让探测发生在类内部（比如 static member function + concept 组合），但这就脱离了“外部模板函数约束”的原始需求
std::void_t<decltype></decltype> 也不行
看似绕开了访问，实则仍失败：&T::private_member 同样受访问控制限制。C++ 标准明确规定：取私有非静态数据成员的地址，必须在类作用域或友元中进行；模板外的 decltype(&T::private_member) 是非法表达式，编译器立刻硬崩。
- 错误信息典型为：
error: invalid use of private member 'private_member' of class 'X' -
std::void_t只能兜住“类型不存在”这类 SFINAE 友好错误，兜不住“访问违规”这种硬错误 - 哪怕你把
private_member改成protected，且模板在派生类中实例化，依然不可靠——依赖继承关系和实例化点，不可控
真正可行的路径：靠友元 + 静态探测函数
若你控制被约束类型的定义（即能改那个类），最稳做法是提供一个公有、无副作用的静态探测接口，由类自身暴露私有成员的存在性。
- 在类内部加一个
static constexpr bool has_private_member_v = true;，或更通用的static constexpr auto private_member_tag() { return std::true_type{}; } - 模板函数通过
requires { T::private_member_tag(); }或requires std::is_same_v<decltype std::true_type></decltype>检查 - 这个探测不触碰私有成员本身，只依赖公有静态接口，完全规避访问控制
- 若类不能修改（如第三方库类型），则无法安全、通用地从外部断言其私有成员存在——这是语言设计的有意限制，不是技巧缺失
容易被忽略的关键点
所谓“检测私有成员”，本质上是个伪需求。模板函数不该也不需要知道参数类型的私有实现细节；真正该约束的是**公有契约**：比如是否支持某种序列化协议、是否满足某个概念接口、是否有公有 value() 或 id() 访问器。
- 强行钻私有成员的空子，往往意味着设计已偏离面向接口编程原则
- 即便用宏、特化、ADL 等奇技淫巧绕过，也会导致代码不可移植、不可维护、与未来标准不兼容
- 最务实的做法：推动上游类型添加公有 trait 或 concept 支持，或封装一层适配器类暴露所需能力
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
