java浅拷贝BeanUtils.copyProperties引发的RPC异常
内容提要
最近参与了一个攻坚项目，测试时间因为其他流程原因耽搁了好几天。在排查过程中发现一个异常，经过分析发现是因为BeanUtils.copyProperties方法导致的。解决方案是去掉该方法，进行手动赋值。反思时，建议使用MapStruct替代BeanUtils.copyProperties。
延伸解读
浅拷贝为何引发RPC异常
BeanUtils.copyProperties属于浅拷贝，只调用子对象的set方法，不会深拷贝所有属性，导致引用指向同一内存地址。在RPC调用中，JSF反序列化时因找不到对应类，会将对象转换为Map，从而抛出ClassCastException。这提醒我们，在跨服务传输对象时，浅拷贝可能隐藏类型丢失风险。
排查思路的启示
作者从怀疑报文格式入手，先后与提供方、调用方协作验证，最终通过单测和代码审查定位到BeanUtils.copyProperties。这种逐步排除、多方协同的排查方式，对于解决类似隐蔽的序列化问题具有参考价值，也说明单测在确认服务端接收报文时的关键作用。
替代方案与使用建议
文章建议在转换较多时使用MapStruct替代BeanUtils.copyProperties，并强调谨慎使用后者。手动赋值虽然原始，但能避免浅拷贝带来的隐患。这反映出在对象转换场景中，选择更可控、更稳定的实现方式，往往比依赖便捷工具更可靠。
Q&A
为什么在项目中使用BeanUtils.copyProperties会导致异常？
因为BeanUtils.copyProperties属于浅拷贝，只调用子对象的set方法，可能导致反序列化错误。
如何解决因BeanUtils.copyProperties引发的RPC异常？
解决方案是去掉BeanUtils.copyProperties，进行手动赋值。
在什么情况下建议使用MapStruct替代BeanUtils.copyProperties？
如果转换比较多，建议使用MapStruct来替代BeanUtils.copyProperties。
项目测试时间延误的原因是什么？
测试时间因其他流程原因耽搁了好几天。
在排查异常时，如何确认报文格式没有问题？
通过模拟报文和使用测试工具进行验证，确认服务端收到的报文格式没有问题。
反思中提到的“越原始的越稳定”是什么意思？
这句话强调了简单实现的稳定性，复杂的实现可能引入更多问题。
