C++ 没有原生静态反射因 C++23 reflexpr 被延期，现有方案靠 constexpr + 模板手搓类型描述，需显式特化、字段顺序严格匹配、不支持自动继承展开，且依赖头文件可见性。
为什么 C++ 没有原生静态反射，但 constexpr + 模板能凑出可用方案
因为标准没落地——C++23 的 reflexpr 被延期了，现在所有“静态反射”都是手搓的模拟。核心思路是：用模板元编程在编译期生成类型描述信息，再靠 constexpr 函数把字段名、偏移、类型等“算出来”。它不是魔法，是硬编码 + 递归展开 + SFINAE/Concepts 筛选的组合技。
常见错误现象：static_assert 报错说“无法在常量表达式中调用非 constexpr 函数”，或模板实例化爆炸导致编译卡死、内存爆满。
- 必须给每个需反射的类型显式特化一个描述结构（比如
struct reflect<MyStruct>），自动推导目前不可靠 - 字段顺序必须和定义一致，否则
offsetof计算偏移会错（尤其有[[no_unique_address]]或位域时） - 不支持继承链自动展开；基类字段要手动合并进派生类的反射描述里
REFLECTABLE 宏 + constexpr 字段遍历的实际写法
这是目前最轻量、可落地的方案：用宏注入一个静态成员函数，返回 std::array 形式的字段元数据（名字、类型 ID、偏移）。关键不在“怎么定义”，而在“怎么保证不崩”。
使用场景：序列化到 JSON、打印调试信息、生成绑定代码（如给 Lua 用）。
立即学习“C++免费学习笔记（深入）”；
- 宏里必须用
__VA_ARGS__展开字段列表，并为每个字段生成一个field_info<T, &T::field_name>实例 - 字段类型不能是不完整类型（比如前向声明的 class），否则
sizeof和offsetof在 constexpr 上下文里不被允许 - 避免在字段名字符串里用空格或特殊符号——
constexpr std::string_view不支持运行时构造，只能用字面量
示例片段：
struct Person {
int id;
const char* name;
};
REFLECTABLE(Person, id, name)这会生成 Person::reflect()，返回含两个 field_info 的数组，每个带 .name() 和 .offset()。
用 std::tuple 模拟字段容器时的 ABI 和性能陷阱
有人用 std::tuple 存字段引用，再配 std::apply 遍历——看起来干净，但实际很危险。
性能影响：每次访问字段都要走 tuple 的索引解包，编译器不一定能完全内联；更糟的是，std::tuple 的内存布局不保证与原始 struct 一致，无法安全用于 memcpy 或网络序列化。
- 不要对
tuple做reinterpret_cast<char*>(&t)取地址——它可能插入填充字节 -
std::get<i>(t)返回的是引用，但如果 tuple 是临时对象，引用会悬空（尤其在 constexpr lambda 里） - MSVC 对
constexpr std::tuple支持滞后，Clang 15+ 更稳；GCC 12 开始支持，但深度嵌套仍可能报 “instantiation depth exceeded”
为什么别碰 __PRETTY_FUNCTION__ 解析做反射
有人试图从编译器生成的函数签名字符串里正则提取字段名——这在技术上可行，但属于自毁型方案。
错误现象：代码在 Clang 下能跑，换到 GCC 就崩；加个 [[maybe_unused]] 属性后字段消失；或者仅因开了 -O2，编译器优化掉调试信息导致字符串为空。
-
__PRETTY_FUNCTION__是非标准扩展，格式随时可能变（GCC 13 已调整模板参数打印方式） - 无法在
constexpr上下文中使用——字符串内容不是常量表达式 - 连基本的 const/volatile 修饰都可能解析错，更别说模板参数推导或别名类型还原
真要省事，不如老老实实用宏标记字段；想彻底自动化，等 C++26 的 reflexpr 吧——现在硬啃字符串就是在给未来埋雷。
最易被忽略的一点：所有静态反射方案都依赖“类型定义可见性”。头文件没正确包含、模板未显式实例化、或用了 PCH 导致宏定义顺序错乱，都会让反射信息静默失效——它不会报错，只会返回空数组或默认值。
