历史
Swift的反射能力在Swift 5.0的ABI稳定性计划中进行了根本设计。之前，反射依赖于每个工具链版本变化的不稳定编译器内部功能。引入了Mirror API，以提供一个稳定的公共接口用于运行时类型检查，使调试工具和通用日志记录没有编译时类型知识成为可能。这需要一种能够在库演进中幸存的元数据格式，因为结构体布局可能在不同版本之间发生变化。
问题
当一个结构体被标记为健壮（在库演变模式下，公共类型的默认情况）时，编译器无法为其存储属性硬编码固定的内存偏移量。如果硬编码，库作者在未来的发布中添加、删除或重新排序字段将会破坏二进制兼容性。此外，反射系统必须暴露足够的元数据，以在运行时重构类型的字段名称和类型，同时尊重隐藏实现细节的健壮边界。
解决方案
Swift编译器将字段描述符发射到二进制元数据的__swift5_fieldmd区段。这些描述符不包含静态偏移量；相反，它们存储相对偏移访问者或实例化时布局计算，在运行时解析实际内存位置。对于健壮类型，元数据包含一个字段偏移量向量，当当前进程实例化该类型时填充。这样的间接性允许Mirror API使用计算得到的偏移量遍历属性，这些偏移量适应于在运行时加载的特定版本的库，保持ABI稳定性和反射能力。
import Foundation struct ResilientConfig { let timeout: Double private let apiKey: String // 尽管是'private'，仍可被Mirror访问 } let config = ResilientConfig(timeout: 30.0, apiKey: "secret") let mirror = Mirror(reflecting: config) for child in mirror.children { print("Property: \(child.label ?? "unnamed"), Value: \(child.value)") }
一个模块化的iOS应用架构将Networking模块（闭源SDK）与Analytics模块（内部开发）分开。Networking模块返回复杂的配置结构，包含不应通过公共获取器暴露的私有身份验证令牌，但Analytics团队需要记录所有配置参数以调试间歇性超时。
解决方案 1: 公共字典转换
Networking团队可以暴露一个方法toDictionary()，手动将字段映射到字符串。
优点: 编译时类型安全，明确控制暴露数据，性能快。
缺点: 每当结构体更改时需要维护；无法在SDK更新中反映添加的新字段而无需重新编译客户端；如果开发者忘记过滤，则暴露敏感字段。
解决方案 2: Objective-C 运行时反射
利用valueForKey:通过NSObject桥接。
优点: 对于有Objective-C背景的开发者来说很熟悉。
缺点: Swift结构不是NSObject子类；强迫**@objc符合性将值语义更改为引用语义，并显著增加二进制大小；无法与原生Swift**类型一起使用。
解决方案 3: Swift反射通过Mirror****
实现一个通用日志记录器，使用**Mirror(reflecting:)**遍历所有存储属性，无论访问控制如何。
优点: 自动适应SDK更新中的新属性，无需重新编译；尊重健壮边界；与值类型和泛型代码一起使用。
缺点: Mirror为其内部存储分配堆内存，不适合高频日志记录；绕过访问控制，可能暴露私有秘密，如果不通过CustomReflectable过滤；无法反射C位字段或计算属性。
选择的解决方案
团队采用了解决方案 3，并创建了一个包装器，检查CustomReflectable的符合性，以允许Networking SDK提供一个安全视图。Networking模块实现了customMirror，以排除apiKey，同时暴露timeout和其他安全字段。
结果
Analytics模块成功记录了通过三个主要的SDK更新的配置状态，而没有出现重大变化。然而，当Networking团队为包含位字段的低级套接字选项添加了一个C结构包装器时，那些特定的字段在日志中显示为空。这需要文档来解释Mirror的限制，而其余的配置继续自动反射。
Mirror如何在反射自引用数据结构时防止无限递归，开发者在实现CustomReflectable时肩负什么责任？Mirror通过在反射时追踪类实例的身份来检测引用周期。当遇到一个类实例时，它会检查该对象是否已经存在于当前递归栈中；如果是，它会停止遍历，以防止堆栈溢出。对于值类型，仅当它们包含形成循环的引用时才会发生递归。然而，当开发者实现CustomReflectable并手动构造一个带有children的Mirror时，运行时无法检测到该自定义构造中的循环。开发者必须确保children序列不会创建无限循环，例如，通过检查递归深度限制或维护自己的访问集，在为类图结构构建自定义反射时。
为什么通过Mirror反射一个struct有时会报告与实际编译布局不同的内存布局，尤其是对于包含位字段或联合的C结构?
Swift的反射元数据是为Swift类型设计的，并使用Clang导入器元数据进行C互操作。C位字段和联合不会映射到具有稳定地址的独立Swift存储属性；它们被表示为不透明存储或内联填充，存在于Clang导入器的类型翻译中。Mirror API需要可寻址的字段来构建其children集合。因此，位字段对反射不可见，因为它们在__swift5_fieldmd区段中缺乏字段描述符，而联合成员可能会因元数据描述的是联合容器而显示为重叠或类型不正确。这是一个根本的限制：Mirror反射的是类型的Swift视图，而不是底层的C布局。
通过Mirror访问属性的性能成本与直接访问的性能成本相比如何，并且为什么在读取属性计数与读取属性值之间的成本是不对称的?
通过Mirror访问属性比直接访问慢几个数量级，因为它涉及运行时元数据查找，为Mirror实例分配堆内存，以及通过存储在类型元数据中的字段访问函数的间接调用。读取children计数需要解析字段描述符元数据以确定存储属性的数量，这是__swift5_fieldmd区段的相对快速扫描。然而，访问实际的值需要为每个字段调用值见证或专门的访问函数，这可能涉及数据复制、管理ARC类型的引用计数，以及跨越健壮边界。对于类，这项成本包括Objective-C运行时检查。因此，迭代mirror.children以提取值的开销高于简单检查mirror.children.count，使得Mirror尽管在调试中有用，但不适合热路径。