RestAssured泛型封装body方法无法支持File与FileInputStream问题求解

泛型方法不兼容File和FileInputStream的核心原因 #

RestAssured的body()方法通过重载实现不同类型请求体的适配，且方法重载是编译期静态绑定的，结合泛型的类型擦除特性，就会出现适配失败的问题：

• 泛型方法的类型擦除会影响重载匹配
  你定义的泛型方法public <T> Response postAMember(T body)编译完成后会被类型擦除，参数会被转为Object类型，方法内部调用body(body)时，编译器只会静态匹配到RestAssured的body(Object object)重载，不会根据运行时实际传入的File/FileInputStream类型，动态匹配对应的body(File file)或body(InputStream inputStream)重载。
• body(Object)和接收文件、流的body()重载逻辑完全不同
  body(Object)方法的默认逻辑是用框架内置的JSON序列化器（Gson/Jackson）将传入的对象序列化为JSON字符串作为请求体：
  • 你测试通过的4种类型（String、POJO、Map、Gson JsonObject）都是序列化器原生支持的类型，序列化后输出的是符合预期的请求载荷，因此请求正常。
  • 传入File类型时，序列化器会直接将File对象本身的属性（如文件路径、是否可读、是否为目录等）序列化为JSON，而非读取文件内存储的载荷内容，服务端收到非法JSON结构就会返回400 Bad Request。
  • 传入FileInputStream类型时，IO流对象包含大量JDK底层不可序列化的内部字段，序列化过程中就会触发字段冲突的异常，也就是你遇到的declares multiple JSON fields named next报错。
• 单独重载的方法能正常运行的原因
  你单独定义的postAMember(File body)和postAMember(FileInputStream body)重载方法，编译期就能明确匹配到RestAssured对应的body(File)和body(InputStream)重载，这两个方法的逻辑是直接读取文件/流的二进制内容作为请求体，不会走JSON序列化逻辑，因此运行符合预期。

内容的提问来源于stack exchange，提问作者VinodGulia