通过REST接口下载的二进制文件与原始文件不一致

java-chassis-dependencies版本：2.6.0

文件下载流程：浏览器---》服务A接口---》服务B接口
接口响应信息：
服务B接口返回类型：FilePart
服务A接口返回类型：ReadStreamPart

**问题现象：
直接使用Postman调用服务B接口下载文件与原始文件二进制一致
使用Postman调用服务A接口下载文件与原始文件不一致
通过浏览器下载文件与原始文件不一致**

参考文件下载开发指导：https://huaweicse.github.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/general-development/file-download.html

1. 服务提供者是可以直接返回Part类型（FilePart、ReadStreamPart都是Part实现）
`如果需要根据请求参数动态创建临时文件，下载完成后，将临时文件删除，可以采用 Part 类型的参数。

@GetMapping(path = "/file")
public Part file(String content) throws IOException {
File file = createTempFile(content);
return new FilePart(null, file)
.setDeleteAfterFinished(true)
.setSubmittedFileName("test.txt");
}`

2. 服务消费者统一使用 org.apache.servicecomb.foundation.vertx.http.ReadStreamPart 处理文件下载。
服务A也是使用ReadStreamPart接收的服务B的响应，由于目的是把文件返回给用户，所以直接将ReadStreamPart透传给web端

在文档中看到关于ReadStreamPart的如下描述，感到很疑惑：
**在得到ReadStreamPart实例时，并没有完成文件内容的下载，调用save系列方法才开始真正从网络上读取文件数据。**

**请问，ReadStreamPart不能在接口间透传吗？为什么文本文件不会出错，对于部分二进制文件会出现下载后不一致的情况？**

Read the referenced file-download guide and trace the Service B FilePart to Service A ReadStreamPart to browser path. Reproduce the binary mismatch with Postman and a browser, then inspect ReadStreamPart's save behavior and the Part implementations. Done means explaining whether passthrough is supported and identifying a verified fix or documentation change.

Written by the indexing model from the issue text.