C++原生无反射是因零成本抽象设计原则，拒绝为不用反射的代码引入运行时开销；需通过宏注册、constexpr元编程或第三方库手动补全，但均有局限性和维护成本。
为什么 C++ 原生没有反射，但你又总想用
C++ 标准至今没提供运行时类型信息（RTTI）之外的反射能力——typeid 和 dynamic_cast 只能告诉你“是不是某个类”，不能列出成员变量、调用私有函数、或根据字符串名取字段。这不是编译器偷懒，而是设计取舍：反射需要元数据，而 C++ 追求零成本抽象，不希望为不用反射的代码埋 runtime 开销。
所以当你看到 Python 的 getattr(obj, "x") 或 C# 的 typeof(T).GetField("y")，别想着“C++ 也能一行搞定”。它得靠人补，而且补法不止一种。
宏 + 类型注册是最常用、最可控的模拟方式
核心思路很简单：用宏在定义类时顺手把字段名、类型、偏移量等信息注册进一个全局表；运行时靠字符串查表，再用指针偏移+类型转换完成读写。
- 必须手动在每个类里加宏，比如
REFLECTABLE(x, y, name)，漏一个字段就反射不到 - 字段顺序和声明顺序必须严格一致，否则
offsetof算出的偏移会错（尤其当有虚函数或基类时） - 不能反射模板实例化后的具体类型（如
std::vector<int>），除非你为它单独注册——宏本身不展开模板参数 - 示例片段：
#define REFLECTABLE(...) \ static const std::vector<FieldInfo>& get_fields() { \ static std::vector<FieldInfo> fields = {__VA_ARGS__}; \ return fields; \ }然后每个字段用FieldInfo{"name", offsetof(MyClass, x), typeid(int)}构造
constexpr + 模板元编程能做编译期反射，但只适用于有限场景
C++20 的 std::tuple_element_t、std::is_aggregate_v 和自定义 reflexpr-like 宏（非标准）可推导结构体字段数、类型、甚至名字（靠编译器扩展如 GCC 的 __PRETTY_FUNCTION__ 解析），但它本质是“生成代码”，不是运行时查询。
立即学习“C++免费学习笔记（深入）”；
- 无法处理继承链中的字段（基类字段不会自动进入派生类的 constexpr 反射结果）
- 字段名提取高度依赖编译器实现细节，Clang 和 GCC 输出格式不同，
__PRETTY_FUNCTION__解析极易崩 - 对
private成员无效——模板无法绕过访问控制，除非把反射逻辑塞进类内部（破坏封装） - 适合做序列化/打印工具，不适合动态配置加载或插件系统这类真正需要“运行时查名”的场景
第三方库（如 Boost.Describe、magic_enum）能省事，但引入新约束
Boost.Describe 要求你用 BOOST_DESCRIBE_STRUCT 显式标注类；magic_enum 只支持枚举，且依赖编译器输出符号名（GCC/Clang 支持，MSVC 需开启 /Zc:__cplusplus）。它们不是“开箱即用”，而是换了一种手动标注方式。
- 所有库都要求你改源码——加宏、加特化、或继承某个基类，不存在“不改原有类就能反射”
- 调试时看不到反射表怎么构建的，一旦字段名拼错或宏套错层级，错误信息往往指向宏展开中间层，定位困难
- 静态链接时反射表可能被 LTO 优化掉（尤其未显式引用
get_fields()时），需加__attribute__((used))或类似标记保活 - 跨 DLL 边界反射失败很常见：RTTI 信息不共享、类型地址不一致、静态局部变量在不同模块中有多份副本
真正麻烦的从来不是“怎么写第一个反射字段”，而是当项目有 200 个类、3 种构建配置、还要支持热重载时，那一堆宏和注册调用是否还能稳定工作。没人能绕过这个权衡：你要的是灵活性，还是确定性。
