企业官网建设流程全解析

在用Java对接各种第三方系统接口时，文件上传算是最常见的需求之一。但说句实话，multipart/form-data这种格式的接口调用，我见过太多人栽在上面。最典型的场景就是：对接方丢过来一份接口文档，写着"Content-Type: multipart/form-data，参数file为文件，extraParam为业务参数"，然后有人直接把这俩字段塞进一个JSON对象里，用application/json去调，服务端那边死活收不到文件，两边还要来回排查半天。

这篇文章就围绕我自己封装multipart/form-data接口调用工具类的完整过程来写，从协议原理、数据结构设计，到三种主流HTTP客户端的实现写法，再到实际项目中翻过的车和最终沉淀下来的经验。不管你是刚接触文件上传的初级开发者，还是被各种HTTP客户端封装搞烦了的资深工程师，这套思路都可以直接拿去用。

1. 先搞清楚multipart/form-data到底是什么，以及为什么文件上传绕不开它

1.1 为什么不能把整个请求体当成JSON直接发

很多人的第一反应是：HTTP请求就是"URL加参数包"，参数包不分文件还是文本，都拼成一段字符串发出去不就行了？问题在于，文件本身是二进制数据，JSON这种纯文本格式没法直接承载它。

JSON如果要传输二进制，通常得先做Base64编码。Base64会把3个字节扩充成4个字符，文件体积直接膨胀约33%，而且服务端拿到手之后还得做一次解码。对于几十KB的小文件这种方案勉强够用，但几百MB的视频、安装包，走Base64是灾难性的，不仅网络传输量暴增，服务端内存也扛不住。

multipart/form-data解法是：把请求体拆成多个"部件"，每个部件有自己的Content-Disposition（描述字段名、文件名）、Content-Type（描述这个部件的数据类型），相互之间用一串随机生成的boundary分隔。文件部件里直接放原始二进制流，文本字段就放UTF-8编码的文本。这样既有文本又有二进制的请求体，就被一个统一格式完整表达出来了。

1.2 一次标准的multipart请求报文长什么样

我还是习惯从报文层面去理解协议，不然封装工具类时很容易被各种HTTP库的高层API绕晕。一个典型的multipart/form-data请求，去掉HTTP头之后，请求体长这样：

--boundary123 Content-Disposition: form-data; name="extraParam" someBusinessValue --boundary123 Content-Disposition: form-data; name="file"; filename="demo.png" Content-Type: image/png <这里是PNG文件的原始二进制字节流> --boundary123--

这里的boundary123是客户端在请求头里约定好的分隔串：

Content-Type: multipart/form-data; boundary=boundary123

服务端解析时做的事情很简单：按照boundary把请求体切成若干段，每段先读若干HTTP头，遇到空行之后，后面的数据就是这个部件的本体。是文件就落盘，是普通字段就转成字符串。

1.3 boundary分隔符的配对机制是服务端拆数据的关键

需要注意，分隔符不是随便换行的。HTTP协议里，boundary出现在三处：Content-Type头里、每个部件前面（前面带两个短横线--）、以及整个请求体末尾（前面和后面都带两个短横线--）。

那个结尾的boundary123--是终止标记，服务端看到这串字符就认为请求体结束。少了一个短横线，或者边界上多了一个空格，服务端解析就会出问题。

这也是为什么我强烈建议：封装工具类时不要自己手写boundary和分隔规则，直接用HTTP客户端库内置的能力。自己拼字符串做分隔，十有八九会在换行符\r\n还是\n、以及末尾标记上出幺蛾子，排查起来极其痛苦。

2. 工具类的职责边界与数据结构设计

2.1 这个工具类只该做两件事：组装请求体、把响应解析出来

我在设计工具类时定的原则很简单：把multipart请求的"组装"和"解析"封装得足够省心，但对服务端返回的业务结构不做任何假设。

也就是说，工具类不对接具体业务。不管是上传用户头像、上报业务文件还是导入数据，底层都是同一套能力：往指定URL发一个multipart请求，携带若干文件参数和普通字段参数，拿到服务端响应字符串。至于响应是JSON、XML还是纯文本，那都是上层业务的事，工具类只需要把响应原始内容原样返回，再由调用方去解析。

这个边界划分非常重要。我看到过有人把工具类做成"全能类"，里面既处理文件上传，又写死了响应要解析成某个固定DTO，结果换一个接口就改一次工具类，最后整个类变得没法维护。

2.2 multipart参数模型：文件参数与普通表单字段分开管理

multipart请求里的参数天然分两类：普通字段和文件字段。文件字段还可能遇到三种情况：单个文件、多个文件、以及"文件名和文件流分开传"的设计（比如有的接口要求filename单独一个字段，文件内容用file字段）。

我在工具类里定义了一个简单的参数模型，核心结构大概是这样：

public class MultipartParam { // 普通表单字段，顺序敏感，用LinkedHashMap保持写入顺序 private final Map<String, String> textFields = new LinkedHashMap<>(); // 文件字段：fieldName -> 文件信息列表 private final Map<String, List<FileItem>> fileFields = new LinkedHashMap<>(); public static class FileItem { private final String fileName; // 文件名，不传时默认取path最后一段 private final Path filePath; // 文件路径 private final InputStream in; // 或者传输入流 private final String contentType; // 文件类型，不传时按扩展名推断 } }

这里有个设计细节：文本字段和文件字段分开存放，因为在组装请求体时，普通的String参数和二进制流参数的处理逻辑是完全不同的。分开之后，工具类遍历组装时逻辑清晰，也方便后续增加功能，比如文件列表、动态追加参数等。

2.3 工具类的主流程：从参数到可执行请求的四步

有了参数模型，工具类的主流程其实就四步：

1. 校验：URL不能为空，方法为POST（multipart一般也不用GET），至少要有一个文件字段或一个文本字段。
2. 组装：把textFields和fileFields按要求的顺序写入请求体编码器。
3. 发送：设置正确的Content-Type头（含boundary），执行HTTP请求。
4. 解析：读取响应状态码和响应体，返回给调用方。

我在这里刻意把"组装"和"发送"拆开，是因为不同的HTTP客户端库对multipart的写法差异很大，但流程骨架是固定的。将来工程里换HTTP客户端（从HttpURLConnection换成OkHttp这类），只动组装和发送部分，参数模型和调用方的代码都不用改。

3. 三种HTTP客户端实现multipart上传的完整写法

3.1 原生HttpURLConnection：能让你看清协议的每一处细节

如果只是想快速写个工具类又不想引第三方依赖，直接用JDK自带的HttpURLConnection完全可行。它暴露的细节最多，也最容易踩坑。

关键点有三个：

• 必须设置Content-Type: multipart/form-data; boundary=xxxx，这个boundary是你自己生成的随机串。
• 必须设置setDoOutput(true)，否则拿不到输出流。
• 打开输出流写请求体之前，最好调用setChunkedStreamingMode(0)，让JDK用流式分块模式发送，否则小文件没关系，大文件可能因为要计算Content-Length而全部读入内存。

我写过一个最小版本，核心代码如下：

public String uploadByUrlConnection(String urlStr, MultipartParam param) throws IOException { String boundary = "JavaBoundary" + System.currentTimeMillis(); URL url = new URL(urlStr); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("POST"); conn.setDoOutput(true); conn.setDoInput(true); conn.setRequestProperty("Content-Type", "multipart/form-data; boundary=" + boundary); conn.setChunkedStreamingMode(0); conn.setConnectTimeout(5_000); conn.setReadTimeout(30_000); try (OutputStream os = conn.getOutputStream(); BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(os, StandardCharsets.UTF_8))) { // 先写文本字段 for (Map.Entry<String, String> entry : param.getTextFields().entrySet()) { writer.write("--" + boundary + "\r\n"); writer.write("Content-Disposition: form-data; name=\"" + entry.getKey() + "\"\r\n"); writer.write("\r\n"); writer.write(entry.getValue()); writer.write("\r\n"); } // 再写文件字段 for (Map.Entry<String, List<FileItem>> entry : param.getFileFields().entrySet()) { for (FileItem file : entry.getValue()) { String fileName = file.getFileName(); String contentType = file.getContentType() != null ? file.getContentType() : URLConnection.guessContentTypeFromName(fileName); if (contentType == null) { contentType = "application/octet-stream"; } writer.write("--" + boundary + "\r\n"); writer.write("Content-Disposition: form-data; name=\"" + entry.getKey() + "\"; filename=\"" + fileName + "\"\r\n"); writer.write("Content-Type: " + contentType + "\r\n"); writer.write("\r\n"); writer.flush(); Files.copy(file.getFilePath(), os); writer.write("\r\n"); writer.flush(); } } // 结束标记 writer.write("--" + boundary + "--\r\n"); writer.flush(); } int status = conn.getResponseCode(); InputStream respStream = status >= 400 ? conn.getErrorStream() : conn.getInputStream(); try (respStream; BufferedReader reader = new BufferedReader( new InputStreamReader(respStream, StandardCharsets.UTF_8))) { StringBuilder sb = new StringBuilder(); String line; while ((line = reader.readLine()) != null) { sb.append(line); } return sb.toString(); } finally { conn.disconnect(); } }

这套写法最大的问题是：文本字段和文件字段的输出流不能共用同一个低层流。上面代码我用BufferedWriter包装了OutputStream，然后文件部分直接用OutputStream写字节流，中间必须手动flush，否则文本和文件的排列顺序会错乱。

注意：HttpURLConnection在写请求体时，getOutputStream()返回的流和getInputStream()返回的流不能同时存在，必须先关闭输出流才能读输入流。所以上面的代码里，我用了try-with-resources，输出流在括号结束时已经关闭，之后的getResponseCode()和读输入流是安全的。

3.2 Apache HttpClient：MultipartEntityBuilder让代码清爽一半

如果项目里已经在用Apache HttpClient，强烈建议直接用MultipartEntityBuilder，它把boundary、Content-Disposition、Content-Type这些细节全部处理好了，代码量和心智负担都少很多。

我用的是HttpClient 5.x版本，依赖坐标是org.apache.httpcomponents.client5:httpclient5。核心逻辑：

public String uploadByHttpClient(String urlStr, MultipartParam param, String cookieOrToken) throws Exception { try (CloseableHttpClient client = HttpClients.custom() .setDefaultRequestConfig(RequestConfig.custom() .setConnectTimeout(Timeout.ofSeconds(5)) .setResponseTimeout(Timeout.ofSeconds(60)) .build()) .build()) { MultipartEntityBuilder builder = MultipartEntityBuilder.create(); builder.setMode(HttpMultipartMode.EXTENDED); builder.setCharset(StandardCharsets.UTF_8); // 文本字段 for (Map.Entry<String, String> entry : param.getTextFields().entrySet()) { builder.addTextBody(entry.getKey(), entry.getValue(), ContentType.create("text/plain", StandardCharsets.UTF_8)); } // 文件字段 for (Map.Entry<String, List<FileItem>> entry : param.getFileFields().entrySet()) { for (FileItem file : entry.getValue()) { builder.addBinaryBody(entry.getKey(), file.getFilePath().toFile(), ContentType.create(file.getContentType()), file.getFileName()); } } HttpEntity entity = builder.build(); HttpPost post = new HttpPost(urlStr); post.setEntity(entity); if (cookieOrToken != null && !cookieOrToken.isEmpty()) { post.setHeader(HttpHeaders.AUTHORIZATION, "Bearer " + cookieOrToken); } try (CloseableHttpResponse response = client.execute(post)) { String result = EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8); int status = response.getCode(); if (status >= 400) { throw new CustomHttpException("HTTP " + status + ": " + result); } return result; } } }

HttpMultipartMode.EXTENDED这个模式很重要，它会在每个部件的Content-Disposition里额外输出filename*和name*等扩展信息，对中文文件名、特殊字符的兼容性比默认模式好很多。

addBinaryBody有两个重载，一个传File，一个传InputStream。如果只是普通文件，传File最稳妥，因为HttpClient可以拿到文件长度并配合Content-Length做流式传输，不太占内存。只有文件生成后没有落盘、只有内存流时，才考虑传InputStream。

3.3 OkHttp的MultipartBody：轻量项目的首选方案

OkHttp在目前Java/Kotlin生态里普及度很高，它提供的MultipartBody.Builder写multipart请求是所有方案里最直观的。

OkHttp的请求体天然是流式的，MultipartBody本身就是RequestBody的子类，组装完直接丢给Request.Builder就行。

public String uploadByOkHttp(String urlStr, MultipartParam param, String token) throws IOException { MultipartBody.Builder bodyBuilder = new MultipartBody.Builder() .setType(MultipartBody.FORM); // 文本字段 for (Map.Entry<String, String> entry : param.getTextFields().entrySet()) { bodyBuilder.addFormDataPart(entry.getKey(), entry.getValue()); } // 文件字段 for (Map.Entry<String, List<FileItem>> entry : param.getFileFields().entrySet()) { for (FileItem file : entry.getValue()) { RequestBody fileBody = file.getFilePath().toFile().isFile() ? file.getFilePath().toFile().asRequestBody( file.getContentType().toMediaTypeOrNull()) : file.getIn().toRequestBody( file.getContentType().toMediaTypeOrNull(), -1); bodyBuilder.addFormDataPart(entry.getKey(), file.getFileName(), fileBody); } } RequestBody requestBody = bodyBuilder.build(); Request request = new Request.Builder() .url(urlStr) .post(requestBody) .header("Authorization", token == null ? "" : "Bearer " + token) .build(); try (Response response = new OkHttpClient.Builder() .connectTimeout(5, TimeUnit.SECONDS) .readTimeout(60, TimeUnit.SECONDS) .build() .newCall(request) .execute()) { ResponseBody respBody = response.body(); String respStr = respBody == null ? "" : respBody.string(); if (!response.isSuccessful()) { throw new CustomHttpException("HTTP " + response.code() + ": " + respStr); } return respStr; } }

OkHttp有个细节需要特别注意：**同一个OkHttpClient实例内部共享连接池和调度器，应该复用一个Client实例，不要每次调用都new一个。**上面代码为了示例清晰直接new了，真实项目里建议把OkHttpClient声明成单例或Spring Bean，反复复用。

三种方案的定位差异也很明确，我最后整理了这么一张对比表，方便大家直接根据自己的场景选：

4. 文件上传工具类最容易翻车的5个细节，逐个排查

4.1 中文文件名与响应乱码：同一套编码从头用到尾

上传文件时中文文件名出乱码，是最常见的问题。

乱码不是某一个环节的问题，而是整条链路任何一个环节编码不一致都会导致。我从工具类角度排查的顺序是：

1. 请求头里的Content-Type是否带charset=UTF-8，multipart本身不强制编码，但文本字段建议明确带上。
2. 输出流写入时，字节编码是否用了UTF-8。HttpURLConnection方案里，如果忘写了StandardCharsets.UTF_8，默认编码就是本机平台编码，Linux上通常是UTF-8，Windows上可能是GBK，这就会出现"本地好好的，上Linux服务器就乱码"的经典问题。
3. 服务端返回响应时，响应头里的Content-Type是什么编码就按什么解码。有的服务端返回application/json;charset=UTF-8，有的却不带charset。不带charset时按UTF-8解相对安全。

我的做法是：**文本字段写入全部显式指定UTF-8，响应解析时也固定用UTF-8，不依赖平台默认编码。**这样虽然不能百分百兼容那些用GBK解析的服务端，但在绝大多数现代系统里是正确的做法。

4.2 超时参数不是拍脑袋填的，要看实际传输时间和服务端处理时间

上传接口的耗时通常比普通JSON接口高一个数量级，因为文件传输本身占时间，服务端接收完文件后还可能做病毒扫描、文件转码、对象存储上传等操作，这些都会计入响应时间。

超时设置太短，上传上百MB文件时连接被掐断；设置太长，又会让调用方等待到怀疑人生。我的经验值：

• 连接超时（connect timeout）：3~5秒，纯TCP建连，起这个值就够。
• 读取超时（read timeout）：普通小文件给30秒，大文件按"预估上传时间的两倍"来设置，而且最好留出余量给服务端后续处理时间。比如预估传完要10秒，服务端处理要5秒，读超时至少给30秒以上才合理。

我用过很多第三方平台的上传接口，它们的网关普遍在30~60秒没有响应就返回504，所以工具类里默认读超时设60秒是比较安全的。如果确认对接的接口处理非常快，再在调用方覆盖这个值。

4.3 大文件上传：File还是InputStream？会不会内存溢出？

multipart请求里的文件本体，可以来自File（磁盘文件）、byte[]（内存字节数组）、InputStream（任意输入流）。三者的内存行为差异巨大：

• 用byte[]：整个文件必须已在内存中，几百MB的文件直接OOM，只适合几MB以内的小文件。
• 用File：HTTP客户端可以从文件长度推算Content-Length，流式发送，不占内存。这是最推荐的方式。
• 用InputStream：流式发送，但很多HTTP客户端库为了计算Content-Length，会先尝试从InputStream读取并缓冲，如果InputStream本身不可重复读取（比如网络流），有的库会自动切换成chunked编码。chunked编码虽然可用，但部分老旧的服务端框架对chunked支持不友好。

因此，工具类里文件参数的首选是File路径，只有必须用InputStream的场景才用InputStream，并且显式告知调用方"这个文件流会被消费掉，不能重试"。这个原则能帮你避免绝大多数大文件上传导致的内存问题。

4.4 连接泄漏与流释放：最容易查不出原因的问题

工具类封装最怕的就是"用了几次就卡住，或者连接数暴涨"。HttpURLConnection方案里conn.disconnect()如果放在异常分支里忘记执行，连接不会立即释放到连接池，长时间高并发上传时连接数会飙到让人头皮发麻。

Apache HttpClient和OkHttp的连接池机制相对完善，但响应体不关闭同样会泄漏。我之前排查过一个线上问题：上传接口调用量一大，服务端的ESTABLISHED连接数就线性上涨，进程最终无响应。最后定位到是调用方拿到的响应字符串没有读取完就丢弃了，底层连接无法复用，只能重新建连。

所以在工具类里我统一用try-with-resources管理Response/InputStream，无论如何都要保证响应体被完整消费或显式关闭。这是工具类质量的底线。

4.5 重试与幂等：本地重试没问题，但服务端怎么判断？

上传接口的超时或网络抖动非常常见，重试机制几乎是生产环境的刚需。但multipart请求有个特殊性：请求体是一次性流式的，发送失败后整个请求体已消耗，无法原样重发。

比如用File方式上传，失败之后想重试，得重新构建请求体，File对象还在磁盘上，重新打开没问题。但如果是InputStream，这个流的position已经前移了，直接重发会把后半段文件当成整个文件发过去，服务端收到的文件是残缺的。

我建议工具类暴露一个重试入口时，内部做两层处理：

1. 只对File类型的文件参数做自动重试，因为File每次都能重新打开。
2. 对InputStream类型不重试，直接抛异常让调用方自行处理。

另外，很多文件上传接口不是幂等的。客户端重试之前，第一次请求可能已成功，但响应在网络传输中丢了，客户端以为失败又重发，服务端就会收到两份文件。针对这个问题，工具类层面没法完全解决，但可以使用请求ID头部（如X-Request-Id）让服务端去重。在设计工具类时，预留一个可以设置自定义请求头的接口，就是为了应对这类场景。

5. 怎么验证工具类：搭一个本地服务端把上传链路跑通

5.1 用Spring Boot写一个接收multipart文件的测试服务

工具类写完，光靠眼睛看肯定不行，我习惯先在本地搭一个最简服务端来验证整条链路。

用Spring Boot写一个接收上传的Controller非常快：

@RestController public class TestUploadController { @PostMapping(value = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE) public Map<String, Object> upload(@RequestParam("extraParam") String extraParam, @RequestPart("file") MultipartFile file) { Map<String, Object> result = new HashMap<>(); result.put("extraParam", extraParam); result.put("fileName", file.getOriginalFilename()); result.put("fileSize", file.getSize()); return result; } }

先用Postman测一次这个接口，确认服务端工作正常。接下来，把工具类的三个实现分别对接到这个接口，逐个跑，观察返回结果。

这一步能验证很多东西：文本字段是否正常传输、中文文件名是否乱码、文件大小是否一致、响应是否能正常解析。我自己的习惯是，每次改动工具类核心代码，都会跑一遍这个本地链路做回归，比写一堆mock测试踏实得多。

5.2 用curl和Postman做对照实验

工具类传到服务端的请求，和curl发出的是不是同一回事，靠这个对照实验能彻底搞清楚。

先在本地生成一个测试文件，比如5MB的随机文件：

dd if=/dev/urandom of=/tmp/testfile.bin bs=1m count=5

然后用curl手动上传对照：

curl -X POST http://localhost:8080/upload \ -F "extraParam=hello" \ -F "file=@/tmp/testfile.bin;filename=测试文件.bin;type=application/octet-stream"

服务端如果收到的文件名是测试文件.bin，说明curl链路没问题。接着用Java工具类发同样的请求，服务端返回一致，说明工具类没问题。如果不一致，把curl请求体和Java工具类发出的请求体各自dump出来对比，问题瞬间就能定位。

提示：HttpURLConnection方案可以临时在代码里打印请求体内容（注意文件部分不要全量打印，打印boundary和头部信息即可），对比curl的请求体结构，排查边界换行符是否错误。

5.3 测试清单：什么场景才是这个工具类的及格线

我把测试用例分成下面几组，每次改动后至少把这组跑完，才算完成一轮验证：

这里重点说说"多个文件字段"这个场景。有的接口会要求一个字段里传多个文件（比如files字段多次出现），有的要求不同字段分别传不同文件，比如avatar和resume。这两种情况，参数模型的Map设计都要覆盖到，我在测试清单里都会各放一个用例。

6. 真实项目里的取舍与个人建议

6.1 工具类、HTTP客户端封装、现成SDK，怎么选

聊到工具类，总有人问：既然OkHttp、Apache HttpClient封装这么全面，还有Spring的RestTemplate、Spring Cloud OpenFeign，为什么还要自己写一个工具类？

我的看法是：工具类不是替代这些框架，而是把"multipart参数模型"和"HTTP客户端调用"这两层粘合起来的一层薄封装。

如果你项目里只是偶尔上传一两次文件，直接写个私有方法就够了，没必要工具类。但如果系统里多个模块都要上传文件（比如用户头像、工单附件、报表导出文件），而且对接的是同一个或同一类文件服务，那抽一个工具类就非常值。它能把文件参数组装、字符编码、超时设置、响应解析这些容易出错的细节收敛到一处，而不是散落在一堆业务代码里。

如果对接的是成熟的云存储服务，人家已经提供了对应语言的SDK，那就直接用SDK。自己写工具类去拼逻辑反而容易踩SDK已经帮你处理好的暗坑（比如分片上传、秒传、断点续传）。工具类的适用边界，是不上不下——那些既没有SDK、又只是标准multipart接口的服务。

6.2 进度监听和断点续传，真的需要吗

有段时间我特别想把上传进度回调加进工具类里，因为有些业务需要给用户展示"上传中 45%"。但深入一想，multipart请求的进度本质上是"文件字节流已写到Socket的缓冲区"的进度，不是服务端实际接收完毕的进度。Socket缓冲区一旦满了，你传给进度回调的百分比可能已经到100%，但服务端还在慢慢收数据，这个进度对用户其实有误导性。

断点续传更复杂，它需要服务端配合支持分片，标准的multipart请求本身不包含分片语义。如果上传的文件很大、网络不稳定，务必先确认服务端支不支持分片上传接口，不要想着在工具类层面硬造一个断点续传出来。

工具类保持简单，把进度、断点这些能力留给上层的业务模块去对接对应的服务端方案，是我最终的取舍。

6.3 一个让响应解析更稳的小技巧

最后分享一个小技巧，也是我踩过多次坑之后的经验总结：解析服务端响应时，不要假定响应Content-Type一定是application/json。

实际对接过的系统里，有返回text/plain的，有返回text/html的，还有返回空响应体只靠状态码判断成败的。如果工具类里写死"把响应体当JSON解析"，遇到这种接口就会在解析环节抛异常，调用方还得通过各种hack绕过工具类。

所以我的工具类始终返回原始响应字符串，再由各业务模块按需解析。工具类里只做一个最保守的判断：HTTP状态码是否为2xx，是则返回响应体，否则抛带状态码和响应体内容的异常。这样一个简单的约定，让工具类在项目里跑了很久都没再因为"响应格式变化"改过一行代码。

工具类这东西，做得太重就是灾难，做得太轻又没价值。最关键的不是代码量多少，而是要把"文件上传"这件事的基本盘守住：参数组装正确、编码统一、超时合理、流不泄漏、异常可排查。按这个标准去写，不管将来HTTP客户端换成什么，你手里这套工具类都能撑住场面。