C++无法直接用[[attribute]]做字段注解，因其仅为编译器提示且禁止用户自定义语义；可行方案是宏+静态注册表+类型擦除，但需手动注册、不支持自动继承聚合，强反射场景推荐IDL代码生成。
C++ 本身不支持运行时反射和 [[attribute]] 注解的自定义语义，所谓“模拟实现”本质是编译期元编程 + 宏 + 类型注册的组合技，不是真正意义上的反射。
为什么不能直接用 [[attribute]] 做字段注解
C++11 引入的 [[attribute]] 是供编译器识别的提示标记（如 [[nodiscard]]、[[deprecated]]），标准禁止用户定义带参数、带语义的自定义 attribute。即使你写 [[my_attr("id")]]，编译器要么报错，要么忽略——它不会进入 AST，更不会在运行时可查。
- Clang/GCC 对未知 attribute 默认仅警告（
-Wunknown-attributes），但不会保留其内容 - MSVC 的
[[msvc::...]]是私有扩展，不可移植，也不支持任意字符串参数 - 所有主流编译器均不提供 API 让你提取
[[xxx]]中的值并绑定到成员变量上
可行路径：宏 + 静态注册表 + 类型擦除
想让 struct Person { int id; std::string name; }; 支持“获取所有带 Reflect 标签的字段名和类型”，必须手动介入声明过程。典型做法是放弃语法糖，改用宏封装字段定义，并在编译期生成注册信息：
#define REFLECT_FIELD(type, name) \
type name; \
static constexpr auto __reflect_##name = ::reflect::field_info{#name, #type};
struct Person {
REFLECT_FIELD(int, id);
REFLECT_FIELD(std::string, name);
static constexpr auto __reflect_type = ::reflect::type_info{"Person"};
};
- 每个
REFLECT_FIELD展开为字段声明 + 一个constexpr静态变量，携带字段名和类型名字符串 - 类型级信息（如
__reflect_type）用于索引所有字段，构成“伪元数据” - 运行时可通过
Person::__reflect_type查到字段列表，但字段地址需靠偏移计算（offsetof）或模板特化推导
关键限制：无法自动推导字段语义，必须显式调用注册函数
即使你用宏生成了字段描述，C++ 没有机制让 Person 自动“被反射系统发现”。你必须显式调用初始化代码，否则字段信息只是孤立的 constexpr 变量，链接器可能将其丢弃（尤其未 ODR-used 时）：
立即学习“C++免费学习笔记（深入）”；
- 必须在某个 .cpp 文件中写
REFLECT_REGISTER(Person);，触发静态变量构造或模板实例化 - 若字段含非 trivial 类型（如
std::vector），offsetof不适用，需用std::tuple+std::index_sequence构建访问器 - 不支持继承链上的字段聚合——基类字段不会自动出现在派生类的反射列表里，需手动合并
替代方案建议：用 Python/IDL 生成 C++ 代码
真正需要强反射语义（如序列化、RPC、编辑器集成）的项目，硬啃 C++ 宏元编程性价比极低。更稳健的做法是：
- 写一个简单 IDL（如 YAML 描述结构体字段 + 标签），用 Python 脚本生成带反射支持的 C++ 类（含
for_each_field接口） - 用 Clang LibTooling 解析 AST，提取真实
[[clang::annotate("json")]]这类扩展 attribute，生成反射元数据头文件 - 接受现实：对调试友好场景，用
std::source_location+printf式日志代替“运行时字段遍历”
所有“纯 C++ 实现反射”的开源库（如 RTTR、Boost.Hana）都依赖宏注入或外部代码生成——没有魔法，只有取舍。最容易被忽略的一点：一旦引入反射，单元测试必须覆盖字段增删场景，否则宏漏写或注册遗漏会静默失效。
