C++标准不支持运行时反射，所有反射均为编译期模拟或工具生成；typeid和dynamic_cast仅提供类型身份与安全转型，无法获取字段名、偏移等结构信息。
C++ 标准不支持运行时反射，所有“反射”都是编译期模拟或外部工具生成的伪反射。你没法像 Python 的 getattr 或 Java 的 Class.getDeclaredFields() 那样在运行时动态查一个类有哪些成员——这是语言设计决定的，不是技巧不到位。
为什么不能直接用 typeid 或 dynamic_cast 获取字段信息？
这两个机制只提供类型身份（type identity）和安全向下转型能力，不携带任何结构描述：typeid 返回的 std::type_info 没有字段名、偏移、类型列表；dynamic_cast 依赖虚函数表，但虚表本身不暴露成员布局。试图靠它们枚举成员会立刻撞墙。
- 常见错误现象：写了个模板函数想遍历
decltype(obj)的所有 public 成员，结果编译失败——C++ 没这种语法 - 使用场景：日志序列化、配置绑定、单元测试断言自检 —— 这些需求真实存在，但必须绕开语言限制
- 参数差异：有些第三方库（如 refl-cpp）用宏注册字段，宏展开后才生成可访问的元数据；没宏就等于没元数据
工程上最可行的路径：宏 + 编译期注册 + constexpr 查表
主流方案（refl-cpp、magic_enum 的思路）本质是让开发者显式声明“我要反射这个类”，然后用宏触发代码生成，把字段名、类型、偏移打包成 constexpr 数据结构。它不是魔法，是契约：你写宏，它才给你表。
- 实操建议：在类定义后紧接
REFL_AUTO(type_name, field1, field2)宏调用（具体宏名依库而定），否则该类完全不可反射 - 容易踩的坑：字段名拼错、访问权限不符（private 字段需 friend 或 getter）、宏未包含对应头文件导致 SFINAE 失败
- 性能影响：全部在编译期完成，运行时零开销；但宏会增加预处理时间和二进制体积（每个反射字段约 20–50 字节静态数据）
Clang 插件 / libclang 方案适合什么人？
如果你控制整个构建链（比如公司内部框架），且能接受额外构建步骤，可以基于 Clang AST 提取类定义，生成 C++ 元数据源文件。这比宏更“自动”，但也更重。
立即学习“C++免费学习笔记（深入）”；
- 使用场景：大型遗留 C++ 项目需要批量为已有类添加反射，又不愿/不能改源码加宏
- 常见错误现象：“找不到 AST 节点”——因为插件没正确解析模板实例化，或头文件路径未传给 libclang
- 兼容性影响：Clang 版本强绑定（如 clang-15 插件无法用于 clang-17），GCC/MSVC 完全不支持
- 示例关键点：插件中用
clang::RecordDecl::fields()遍历字段，用getFieldName()->getName()取名，再生成constexpr struct { const char* name; size_t offset; } fields[]
真正难的从来不是“怎么写反射代码”，而是决定哪些类值得加宏、字段变更时如何同步更新反射声明、以及当同事忘了加宏时，调试器里看到空元数据表那种沉默的绝望。
