__PRETTY_FUNCTION__是最可行的起点，因其在GCC/Clang下将模板实例化后的完整签名（含字段名）编译为字符串字面量，配合模板参数锚定可提取结构体字段名；而宏拼接无法绑定结构体上下文，reflexpr尚未被主流编译器实现，故该宏仍是当前纯头文件、零依赖方案中最稳定可靠的编译期入口。
为什么 __PRETTY_FUNCTION__ 是最可行的起点
标准 C++ 没有反射，无法直接获取字段名字符串。但借助编译器扩展和模板元编程，__PRETTY_FUNCTION__（GCC/Clang）或 __FUNCSIG__（MSVC）能暴露模板实例化时的完整签名，其中包含字段名——这是目前最稳定、无需外部工具、纯头文件可实现的路径。
关键在于：它不是“读取结构体”，而是让编译器在推导模板参数时，“把字段名写进函数签名里”，再用字符串字面量提取出来。
常见错误是试图对任意结构体无条件使用，但实际必须满足：
- 字段类型需支持模板偏特化（不能是 void、数组未指定大小等）
- 结构体不能含匿名联合或位域（它们不参与名字修饰）
- 必须显式触发模板实例化（比如调用一个函数模板），否则编译器可能优化掉
如何用模板 + __PRETTY_FUNCTION__ 提取单个字段名
核心思路是定义一个模板函数，接收字段的地址（或引用），利用其类型和地址在模板参数中“锚定”该字段，再通过解析 __PRETTY_FUNCTION__ 中的形参名部分截取出字段名。
示例（简化版）：
立即学习“C++免费学习笔记（深入）”；
template <typename T, typename U>
constexpr auto field_name(U T::*ptr) {
constexpr auto s = __PRETTY_FUNCTION__;
// 假设 s 形如 "...field_name<S, int>(int S::*)"
// 实际需用 constexpr 字符串处理库（如 Boost.MP11 的 string_view 模拟）截取 "int S::*" 后的标识符
// 这里跳过复杂解析，强调关键约束：
}
实操建议：
- 不要手写正则或运行时解析 —— __PRETTY_FUNCTION__ 内容非标准，GCC 和 Clang 格式不同
- 优先用已验证的轻量库，如 magic_enum（仅限枚举）或 reflexpr（C++23 实验性，尚未普及）
- 若坚持手撸，只针对 GCC 测试，并用 static_assert 校验 __PRETTY_FUNCTION__ 是否含预期模式，避免静默失败
为什么不能用宏简单拼接 #__FIELD_NAME__
有人尝试 #define FIELD_STR(field) #field，但这只能得到宏参数字面量，不是结构体真实字段名 —— 它不感知结构体上下文，FIELD_STR(age) 总是生成 "age"，哪怕该字段根本不存在于目标结构体中。
更严重的问题：
- 无法做编译期校验：字段名拼错、类型不匹配、const/volatile 修饰差异全无提示
- 无法处理同名字段（如多个结构体都有 id）—— 缺乏作用域绑定
- 与结构体定义脱节：字段重命名后，所有宏调用不会自动更新，极易遗漏
所以，真正可靠的方案必须将字段名和结构体类型强绑定，而宏做不到这点。
C++23 reflexpr 能否解决？目前还不能放心用
reflexpr(S) 理论上允许获取结构体的反射信息，包括字段名，但现实是：
- GCC 14、Clang 18 均未实现 reflexpr（截至 2024 年中）
- MSVC 仅在预览版中提供极有限支持，且禁用优化时行为不稳定
- 标准库无配套元函数（如 get_member_name_v<S, &S::age>）可用
这意味着：如果你现在写生产代码，依赖 reflexpr 就等于锁定一个不可用的未来特性。临时方案仍是基于 __PRETTY_FUNCTION__ 的手工解析，或接受运行时注册（如 protobuf 的 descriptor）。
最容易被忽略的一点：字段名字符串本身在编译期是否“真正常量”——即使你提取成功，若未用 constexpr 字符串类包装，它可能无法用于非类型模板参数或 static_assert 消息中，导致二次降级为运行时逻辑。
