6.2 运行时反射与动态消息
6.2 运行时反射与动态消息：读整块石碑
本节摘要：运行时反射让程序在不知道具体消息类型的情况下遍历字段、读写值、读取 option 标注——它是通用序列化工具、消息审计、契约驱动框架的共同地基。本节拆解反射 API 的三层结构、写一个通用的字段遍历函数、说明 DynamicMessage 在"没有生成代码"场景下的角色与代价。读完你应当能写出类型无关的消息处理代码，并判断反射方案的适用边界。
本章第二站：6.1 负责往描述符刻字，本节负责运行时读碑。反射也是上一节脱敏案例里"日志库遍历字段"的正式展开。
反射的三层结构
以 Go 为例（各语言 API 形态不同、概念一致），反射的入口从消息实例往上走三层：
proto.Message 实例 → proto.Message 反射接口：拿到字段视图、清空、修改 → descriptor：字段的名字、编号、类型、option 标注（只读的契约元数据）
第一层拿到的是值的镜像（这个消息实例里字段 3 当前是什么值），第三层拿到的是契约的镜像（字段 3 定义成什么类型、挂了什么 option）。第 1.1 节三层职责模型在这里出现了一个有趣的合流：IDL 契约层的信息，通过反射在运行时变得可编程——proto 文件里的一切都在运行时活着。
通用遍历：一个函数处理任意消息
脱敏、审计、统计字段覆盖率……这类需求的公共形态是"对任意消息的每个字段做点什么"。通用循环的骨架：
func WalkMessage(m proto.Message, visit func(fd protoreflect.FieldDescriptor, v protoreflect.Value)) { mr := m.ProtoReflect() md := mr.Descriptor() fields := md.Fields() for i := 0; i < fields.Len(); i++ { fd := fields.Get(i) if !mr.Has(fd) { continue // 尊重 presence：没赋值的字段不访问 } v := mr.Get(fd) if fd.IsList() { // repeated：逐元素递归访问 list := v.List() for j := 0; j < list.Len(); j++ { visit(fd, list.Get(j)) } } else { visit(fd, v) } } }
三个工程要点。其一，Has 检查不可省：proto3 的 0 值盲区在反射侧同样存在，Has 区分"赋了 0"与"没赋值"，统计场景混用会得出错误结论。其二，嵌套消息的递归：visit 回调里检测值的类型是消息就再调 WalkMessage——字段级标注（如脱敏）通常只处理叶子，路径级处理（如审计日志记完整字段路径）要维护递归栈。其三，读取自定义 option：fd.Options() 返回的就是第 6.1 节刻进去的铭文，按扩展编号解出 DataClass 或 log_mask——上一节脱敏案例的"日志库改造"，核心就是这一个循环加 option 解码。
DynamicMessage：没有生成代码时怎么办
反射操作的是已有生成代码的消息实例；另一类场景更极端——手里只有描述符，没有任何生成代码：运维工具解析线上抓包、网关透传时按需读取路由字段、测试工具构造任意合法消息。DynamicMessage 就是运行时用描述符"捏"出来的消息：它的字段集合来自描述符，值存储在动态结构里，序列化走第 3 章三把尺子的库化实现（tag 解析→载荷按 wire type 分发→LEN 递归）。
代价必须摆明：DynamicMessage 的每次字段访问都要过描述符查找，比生成代码的静态字段访问慢一到两个数量级；值类型是语言原生的装箱对象，装箱拆装箱开销叠加。所以工程定位很清晰——DynamicMessage 是工具与基础设施的选择，不是业务代码的选择：业务路径永远用生成代码，工具路径（抓包解析器、通用网关、契约测试生成器）才值得付动态性的税。
反射的性能纪律
反射方案落地时的三条纪律：
- 描述符查找结果要缓存：字段编号→FieldDescriptor 的映射在一次进程里不变，用 map 缓存后遍历开销能砍掉大半；
- 热路径分层：网关类服务按第 5.3 节变式案例的做法——消息体不解，只有路由必需的个别字段走反射按需读取，其余字节原样转发；
- 别在反射里做业务逻辑：反射代码的正确性依赖描述符与生成代码的版本一致（都来自同一次 protoc 编译），业务逻辑藏在反射分支里等于把可读性埋进元编程——保持反射层薄、只做分发与标注读取，行为决策留在显式代码里。
实战案例：一个通用抓包解析工具的诞生
背景：排障团队需要解析任意服务的线上 Protobuf 抓包，但不可能给每个服务都装生成代码。操作：工具加载目标服务的 descriptor set（第 4.1 节的 desc.pb 产物，由各服务 CI 构建时导出并归档）；抓包字节用 DynamicMessage 解析——描述符驱动逐字段展开，输出层级化的字段树（名字、类型、值），字段带自定义 option 的（如数据分级）在输出里加标记；支持"只看字段 X"的过滤，过滤实现就是遍历时按 FieldDescriptor 名字短路。结果：一个零生成代码依赖的通用解析器，新服务接入只需扔进它的 desc.pb；对比 decode_raw，输出从裸编号升级为带名字带类型的可读树。解读：这个工具本质上是"decode_raw 的描述符增强版"——第 1 章的勘察铲升级成整套装备；它也验证了 DynamicMessage 的定位：低频、工具型、性能不敏感。变式：把工具倒过来用——输入字段名与值、输出合法字节流，就成了测试造数器；再接上第 4 章插件生成的 mock 规则 option，就是一套契约驱动的测试数据工厂。
本节要点回顾
- 三层结构：消息实例 → 反射接口（值镜像）→ 描述符（契约镜像），契约信息运行时全部活着；
- 通用循环三要点：Has 区分 0 值盲区、repeated 逐元素、嵌套递归带栈；
- 自定义 option 的运行时消费与插件消费共享同一份描述符——一次刻写两条路径；
- DynamicMessage 定位：工具与基础设施的选择，业务路径永远用生成代码，代价是一到两个数量级的访问开销；
- 性能纪律：描述符查找缓存、热路径分层、反射层保持薄。
石碑能读了，最后一站处理"碑装不下"的问题：Any 如何把整块异构消息装进信封、Struct 如何表达类 JSON 的自由结构、以及 proto2 extensions 的历史困境。