Protobuf 对象序列化在多模块依赖中的反序列化陷阱
近期在维护基于 Dubbo 的微服务架构时，遇到了一个比较棘手的序列化问题。项目采用 Maven 多模块构建，涉及算法转换服务 A、通用配置模块 B 以及 Config 服务 C。这些模块通过接口相互依赖，并在 Redis 中进行对象存取。
问题现象
在模块 A 调用服务 C 进行 Redis 读写时，发现了一个诡异的现象：使用 Protobuf 序列化的对象，在模块 B 中存储和读取均正常，但一旦在服务 C 端取出，对象类型始终变成了 HashMap，而非预期的 Protobuf 消息类。
这导致后续业务逻辑无法直接访问字段，必须强制转换或重新解析，严重影响了系统的稳定性。
原因分析
深入排查后发现，问题的根源在于 Protobuf 的反序列化机制对类路径的依赖。
- 序列化过程：对象被转换为字节流存入 Redis，这一步通常没有问题，因为发送方拥有完整的 proto 定义。
- 反序列化瓶颈：当接收方（服务 C）尝试从 Redis 取出数据并还原为对象时，Protobuf 需要找到对应的类定义来映射字节流。如果目标类所在的包或编译产物未正确引入到当前项目的 Classpath 中，Protobuf 无法识别具体的 Message 类型。
- 默认行为：为了保障程序不崩溃，Protobuf 在找不到具体类型描述符时，会将未知字段以
Map<String, Object>的形式存储。这就是为什么我们最终取出的始终是HashMap。
解决方案
要彻底解决此问题，核心在于确保反序列化端能够'看见'目标对象的类型定义。
1. 检查 Maven 依赖
确认服务 C 的 pom.xml 中是否包含了生成该 Protobuf 类的模块依赖。如果对象定义在模块 B 中，而服务 C 仅依赖了接口层而未包含实现层的 proto 编译产物，反序列化必然失败。
<!-- 示例：确保引入了包含 proto 定义的模块 -->
<dependency>
<groupId>com.example</groupId>
<artifactId>module-b-common</artifactId>
<version>${project.version}</version>
</dependency>
2. 统一序列化策略
在多模块项目中，建议将 Protobuf 相关的公共类提取为独立的基础库模块，供所有涉及 RPC 调用的服务引用。这样既能避免重复定义，也能保证序列化/反序列化环境的一致性。
3. 验证修复
完成依赖引入后，重启服务 C 并再次执行 Redis 存取操作。此时反序列化器应能正确加载对应的 Descriptor，返回的对象类型将恢复为预期的 Protobuf 类，而非 HashMap。
总结
在微服务架构下，跨模块的 Protobuf 序列化不仅仅是代码层面的调用，更依赖于构建时的依赖管理。遇到反序列化异常时，优先检查 Classpath 中是否存在对应的类定义，往往比修改序列化逻辑更有效。
