标准C++20无原生编译期反射，需用宏+模板注册字段名、类型、偏移；运行时反射依赖std::any/variant手动维护映射；全自动反射不可行，宏注册是唯一可控路径。
编译期反射：用宏 + 模板注册字段信息
标准 C++20 不提供原生编译期反射，但可通过宏配合模板元编程模拟出“字段名→类型→偏移”的静态映射。关键不是真的反射，而是让编译器在编译时就生成可查的结构描述。
常见错误是试图用 decltype 或 std::is_same 直接推导成员名——C++ 语法不支持运行时获取成员标识符字符串。必须靠宏展开把名字“写死”进类型系统。
- 定义一个全局宏
REFLECT_STRUCT，在结构体声明后调用，如：REFLECT_STRUCT(Person, name, age) - 宏内部用
template<size_t I>特化方式为每个字段生成唯一类型标签（如field_tag<0>），并绑定offsetof偏移和std::type_identity_t<T> - 字段名字符串需用
#name转为字面量，存入constexpr std::string_view数组（C++20 起支持） - 避免在类内直接使用宏定义字段——会破坏封装且干扰 IDE 补全；应保持原始结构体干净，仅在外部注册
struct Person {
std::string name;
int age;
};
REFLECT_STRUCT(Person, name, age); // 展开后生成静态元数据运行时反射：用 unordered_map 手动维护字段映射
若需要真正动态访问（比如从 JSON 字符串构造对象），就得放弃纯编译期方案，改用运行时注册表。这不是“语言级反射”，而是你自己实现的、带类型擦除的字段访问器。
容易踩的坑是裸指针悬挂或类型转换不安全——void* 偏移加法 + reinterpret_cast 极易出错，必须配对验证。
立即学习“C++免费学习笔记（深入）”；
- 每个可反射类型需显式调用初始化函数，如
register_type<Person>() - 字段注册用 lambda 封装读写逻辑：
reg.field("name", [](const void* p) { return &static_cast<const Person*>(p)->name; }, ...) - 读写接口统一返回
std::any或自定义variant<int, string, double>，避免裸void* - 禁止跨 DLL 边界传递反射元数据——RTTI 和
type_info在不同模块可能不一致
auto obj = std::make_unique<Person>(); auto& meta = get_reflection_meta<Person>(); meta.set_field(*obj, "age", 25); // 内部做类型检查与赋值 std::cout << std::any_cast<int>(meta.get_field(*obj, "age")) << "\n";
std::any / std::variant 是运行时反射的底线依赖
没有它们，你就得自己写类型擦除容器或硬编码支持类型列表。C++17 的 std::any 已足够应对多数配置/序列化场景，但注意它不提供运行时类型比较（any.type() == typeid(int) 可用，但不能比 std::type_info 地址）。
性能上，std::any 构造/析构有堆分配开销；若字段全是 POD 类型，可改用 std::variant<int, float, std::string> 避免分配，但需提前穷举所有可能类型。
- 别用
dynamic_cast替代std::any_cast——前者只适用于多态类，且开销更大 -
std::any存储引用需包装成std::reference_wrapper<T>，否则会拷贝 - 若目标平台不支持 C++17，可用 Boost.Any，但注意其异常行为与标准版略有差异
别碰 constexpr if + template parameter pack 的“自动反射”幻觉
有人尝试用 template<auto... Members> 推导结构体字段，但这根本不可行：C++ 不允许将非类型模板参数用于成员指针（&T::field 不是字面量），也无法从 sizeof(T) 反推字段布局。
所有声称“零宏全自动反射”的库，底层必然依赖编译器扩展（如 Clang 的 __reflect）、外部代码生成（如 protobuf 插件）、或限制极严的 POD 结构体 + 字节解析。标准 C++ 下，宏注册仍是唯一可控路径。
真正难的不是注册字段，而是让反射信息能被序列化器、GUI 绑定、脚本桥接等下游模块一致消费——这意味着你要设计一套稳定的元数据 ABI，而不是每次换种用途就重写一遍映射逻辑。
