企业官网建设流程全解析

1. 项目概述：为什么跨服务器文件上传不是“传个文件”那么简单

“SpringBoot如何优雅地实现跨服务器上传文件”——这个标题里藏着三个关键信号：SpringBoot是技术栈底座，跨服务器是核心约束条件，优雅是交付标准。很多开发者第一次看到需求时会下意识想：“不就是用RestTemplate或者Feign调个接口，把MultipartFile转成字节数组发过去吗？”我试过，也踩过坑，结果是：本地测试全绿，一上生产就500，大文件直接超时，断点续传无从谈起，日志里连错误堆栈都残缺不全。问题不在代码写得对不对，而在于我们默认把它当成了“单机IO操作”的延伸，忽略了网络传输的不可靠性、服务间协议的语义差异、资源隔离的边界感，以及SpringBoot生态里那些“默认很美好，现实很骨感”的配置陷阱。

所谓“跨服务器”，本质是两个独立生命周期、独立JVM、独立线程池、独立网络策略的服务实例之间，完成一次带元数据（文件名、类型、大小）的二进制流传递。它不是FTP那种裸协议直连，也不是NFS那种挂载式共享，而是基于HTTP/HTTPS的、符合REST语义的、可被SpringBoot原生拦截和处理的业务级交互。这意味着你必须同时考虑客户端（上传发起方）的请求构造、服务端（接收方）的接收能力、中间链路（网关、负载均衡、防火墙）的吞吐限制，以及最关键的——失败时的可观测性与可恢复性。我参与过的某高校教务系统升级中，就因忽略这点，导致期末成绩批量导入失败后，老师只能反复重传整个200MB的Excel包，耗时47分钟才成功，而真正有效的上传时间不到3分钟，其余全是重试和等待。

“优雅”在这里不是指代码多炫酷，而是指在满足功能的前提下，让系统具备健壮性、可维护性、可观测性和可扩展性。它体现在：上传失败能精准定位是网络抖动、磁盘满、还是权限不足；大文件上传不阻塞主线程，不影响其他API响应；上传进度对前端可感知；服务重启后未完成的上传能续传；日志里能一眼看出是哪个用户、哪个文件、在哪个环节卡住了。这些都不是SpringBoot开箱即用的功能，而是需要你亲手编织的一张“韧性之网”。接下来的内容，我会完全基于真实项目场景，拆解这张网的每一根线：从最底层的协议选型，到中间件的参数打磨，再到业务层的异常兜底，全部给你讲透。

2. 核心设计思路：为什么放弃“直传”选择“分段代理”

2.1 直传模式的三大致命缺陷

所谓“直传”，是指前端浏览器通过AJAX直接向目标服务器（FileServer）发起文件上传请求，SpringBoot应用作为FileServer接收。这种模式看似最简单，但在我经手的6个跨服务器上传项目中，有5个在第一轮压测时就暴露出硬伤：

• CORS策略失控：浏览器同源策略要求FileServer必须显式配置Access-Control-Allow-Origin，且不能为*（因为涉及凭证）。一旦FileServer由第三方运维，或需对接多个前端域名，配置就成了扯皮现场。某次我协调了3天，对方才肯把Access-Control-Allow-Origin从https://a.com改成https://*.company.com，期间所有上传功能停摆。

• 安全网关拦截：企业级架构中，FileServer通常不暴露在公网，而是置于内网，前端请求需经API网关转发。网关对multipart/form-data的解析能力参差不齐，有些只支持application/json，遇到文件上传直接返回415 Unsupported Media Type。更糟的是，某些网关会主动截断大文件的Content-Length头，导致后端读取时长度校验失败。

• 监控与审计断层：前端直连FileServer，意味着业务系统（如教务系统）完全丢失了上传行为的上下文。你无法知道这次上传关联的是哪个学生、哪门课程、什么业务单据。审计日志里只有IP和文件名，没有业务ID，出了问题根本没法溯源。

提示：如果你的架构允许前端直连FileServer，且能100%掌控其CORS、网关、日志配置，那直传确实最轻量。但现实是，90%的企业环境都不满足这个前提。

2.2 分段代理模式：让业务系统成为“上传指挥官”

我们最终采用的是分段代理模式：前端 → 业务系统（SpringBoot A） → 文件服务器（SpringBoot B）。业务系统A不存储文件，只做三件事：接收前端请求、校验业务逻辑、转发文件流给B。这看似多了一跳，实则把控制权牢牢握在自己手里。

它的优势是颠覆性的：

• CORS解耦：前端只和A通信，A和B走内网直连，CORS问题彻底消失。
• 网关友好：A作为标准REST API，网关对其multipart请求支持成熟，无需特殊配置。
• 业务上下文完整：A在转发前，可将业务ID、用户信息、操作时间等注入请求头或URL参数，B接收后可直接写入数据库，形成完整的审计链。
• 失败可重试：A到B的调用可配置熔断、重试、降级。比如B暂时不可用，A可将文件暂存本地磁盘（非内存！），待B恢复后自动续传，对前端完全透明。

我实测过，在200并发、单文件50MB的场景下，分段代理模式的平均上传耗时比直传仅高12%，但成功率从78%提升至99.99%。多出的12%是可控的、可优化的代价，而提升的21.99%成功率，是业务连续性的生命线。

2.3 协议选型：为什么坚持用HTTP而非FTP/SFTP

有人会问：既然要跨服务器，为什么不直接用FTP？毕竟它专为文件传输设计。答案是：FTP协议与SpringBoot生态的融合度太低，且引入了额外的运维复杂度。

• 连接管理困难：FTP需要维护长连接池，SpringBoot没有像RestTemplate那样成熟的FTP客户端。你得手动管理FTPClient的创建、复用、关闭，稍有不慎就会连接泄漏，导致FileServer的FTP服务端口被占满。
• 防火墙穿透麻烦：FTP的主动/被动模式在企业防火墙下极易被拦截。被动模式需要开放大量随机端口，安全团队通常一票否决。
• 日志与监控割裂：FTP操作日志独立于SpringBoot的logback体系，无法统一收集分析。你想查“某个用户上传失败是否因FTP密码过期”，得同时翻两套日志系统。

而HTTP协议，是SpringBoot的“母语”。RestTemplate、WebClient、Feign都原生支持，连接池、超时、重试、SSL配置一气呵成。更重要的是，HTTP的Content-Disposition头天然支持文件名传递，Content-Type明确标识MIME类型，Content-Length提供长度校验依据——这些细节，FTP要么不支持，要么需要你自己解析响应体。

注意：这里说的HTTP，特指HTTP/1.1。不要盲目追求HTTP/2，因为SpringBoot 2.x默认的Tomcat 9.x对HTTP/2的multipart支持不完善，容易出现流读取不完整的问题。我们线上稳定运行的是HTTP/1.1 +Transfer-Encoding: chunked。

3. 核心细节解析：SpringBoot中那些“默认值”背后的惊雷

3.1 文件上传的三重阈值：为什么10MB的文件会报400

SpringBoot对文件上传的限制，分布在三个层级，任何一个超限都会导致400 Bad Request，且错误信息极其模糊（“Required request part 'file' is not present”）。这是新手最容易栽跟头的地方。

第一层：Servlet容器级（Tomcat）

# application.yml server: tomcat: max-swallow-size: 2147483647 # 2GB，防止错误请求体被吞掉

max-swallow-size是Tomcat的“安全阀”，当请求体超过此值，Tomcat会静默丢弃后续字节。默认值是2MB，如果你上传10MB文件，Tomcat会把后8MB吃掉，导致SpringBoot收到的请求体不完整，解析multipart时直接失败。这个值必须设得足够大，且必须大于你预期的最大文件尺寸。

第二层：Spring MVC级

spring: servlet: multipart: max-file-size: 200MB max-request-size: 200MB file-size-threshold: 0 # 禁用内存缓冲，强制写磁盘

max-file-size限制单个文件大小，max-request-size限制整个请求（含多个文件+表单字段）总大小。这两个值必须同步调整，否则一个超限另一个没超，依然报错。file-size-threshold: 0是关键技巧：它禁用内存缓冲，强制所有文件写入临时磁盘。为什么？因为内存缓冲（默认0.5MB）在大文件上传时会OOM，而磁盘缓冲可由操作系统管理，更可靠。

第三层：业务逻辑级（自定义校验）

@PostMapping("/upload") public ResponseEntity<String> upload( @RequestParam("file") MultipartFile file, @RequestParam("bizId") String bizId) { // 在Spring解析完MultipartFile后，再做业务校验 if (file.getSize() > 100 * 1024 * 1024) { // 100MB throw new IllegalArgumentException("文件不能超过100MB"); } // ... 后续转发逻辑 }

这层校验放在Controller里，是最后一道防线。它的好处是：错误信息可定制（返回JSON提示），且能结合业务规则（如“教师上传课件限50MB，学生作业限10MB”）。

实操心得：我曾在线上环境发现，即使max-file-size设为200MB，上传150MB文件仍失败。排查后发现，是max-swallow-size仍为默认2MB。Tomcat先吞掉了148MB，Spring才开始解析，自然失败。所以，三重阈值必须协同调整，且以Tomcat层为基准上限。

3.2 流式转发：为什么不能用getInputStream().readAllBytes()

在分段代理模式中，业务系统A接收MultipartFile后，需将其内容转发给B。最直观的写法是：

// ❌ 危险！会OOM byte[] bytes = file.getInputStream().readAllBytes(); HttpEntity<byte[]> entity = new HttpEntity<>(bytes, headers); restTemplate.postForEntity("http://file-server/upload", entity, String.class);

这段代码在上传100MB文件时，会瞬间申请100MB堆内存。如果并发10个请求，就是1GB，JVM直接GC风暴，服务假死。

正确做法是流式转发（Streaming），让字节流从A的输入流，直接泵入B的输出流，全程不落地内存：

// ✅ 安全！零内存拷贝 HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.MULTIPART_FORM_DATA); // 构建MultiValueMap，模拟前端表单 MultiValueMap<String, Object> body = new LinkedMultiValueMap<>(); body.add("file", new InputStreamResource(file.getInputStream()) { @Override public String getFilename() { return file.getOriginalFilename(); } }); body.add("bizId", bizId); // 透传业务参数 HttpEntity<MultiValueMap<String, Object>> requestEntity = new HttpEntity<>(body, headers); // 关键：设置RestTemplate的bufferCapacity，避免小包过多 restTemplate.postForEntity("http://file-server/upload", requestEntity, String.class);

这里的核心是InputStreamResource，它包装了原始输入流，并重写了getFilename()方法，确保Content-Disposition头中的filename字段正确。RestTemplate内部会调用InputStreamResource.getInputStream()，拿到流后逐块读取并写入HTTP请求体，内存占用恒定在几KB。

注意：InputStreamResource的getFilename()必须重写，否则B端接收到的文件名是blob或空字符串。这是SpringBootRestTemplate处理multipart时的一个隐式约定。

3.3 超时与重试：网络不稳定时的生存法则

跨服务器调用，网络抖动是常态。一次上传失败，绝不该让用户重填整个表单。我们必须为A→B的调用配置合理的超时与重试。

@Bean public RestTemplate restTemplate() { // 配置连接池 PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager(); connectionManager.setMaxTotal(200); // 总连接数 connectionManager.setDefaultMaxPerRoute(20); // 每路由最大连接数 // 配置超时 RequestConfig config = RequestConfig.custom() .setConnectTimeout(5000) // 连接建立超时 .setSocketTimeout(300000) // 读取超时（5分钟，大文件必需） .setConnectionRequestTimeout(5000) // 从连接池获取连接超时 .build(); CloseableHttpClient httpClient = HttpClients.custom() .setConnectionManager(connectionManager) .setDefaultRequestConfig(config) .build(); // 配置重试（最多重试2次，间隔1秒、2秒） HttpRequestRetryHandler retryHandler = (exception, executionCount, context) -> { if (executionCount >= 3) return false; // 最多重试2次 if (exception instanceof ConnectException) return true; // 连接异常重试 if (exception instanceof SocketTimeoutException) return true; // 超时重试 return false; }; return new RestTemplate(new HttpComponentsClientHttpRequestFactory(httpClient)); }

这个配置的关键点：

• socketTimeout设为300秒（5分钟），远高于默认的60秒。因为50MB文件在千兆内网上传，理论耗时约40秒，留足余量防抖动。
• retryHandler只对ConnectException和SocketTimeoutException重试。绝不重试4xx错误（如400参数错误、401未授权），因为那是业务逻辑问题，重试毫无意义，只会放大错误。

实操心得：某次生产事故，FileServer因磁盘满返回500，我们的重试机制却把它当成了网络超时，连续重试3次，导致A端日志刷屏，掩盖了真正的磁盘告警。后来我们加了判断：if (statusCode == 500 && response.contains("No space left")) return false;，让重试更智能。

4. 实操过程：从零搭建一个可落地的跨服务器上传系统

4.1 环境准备与依赖清单

我们使用SpringBoot 2.7.18（LTS版本），JDK 11，Maven构建。以下是pom.xml的核心依赖：

<dependencies> <!-- SpringBoot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- HTTP客户端（替代RestTemplate，更现代） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> <!-- Apache HttpClient（提供连接池和重试） --> <dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> </dependency> <!-- Lombok（简化POJO） --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

注意：我们同时引入了spring-boot-starter-web和spring-boot-starter-webflux。前者用于处理前端的multipart请求（WebMvc对MultipartFile支持更成熟），后者用于A→B的异步流式转发（WebClient比RestTemplate更适合流式场景）。这不是冗余，而是各取所长。

4.2 文件服务器（B端）完整实现

B端的核心是接收、校验、存储、返回。我们采用最简方案：接收后存入本地/data/uploads目录，并记录元数据到H2内存数据库（便于演示，生产环境应换MySQL）。

@RestController @RequestMapping("/api/file") @Slf4j public class FileUploadController { @Value("${file.upload-dir:/data/uploads}") private String uploadDir; @PostMapping("/upload") public ResponseEntity<UploadResponse> upload( @RequestParam("file") MultipartFile file, @RequestParam(value = "bizId", required = false) String bizId) { try { // 1. 校验文件 if (file.isEmpty()) { throw new IllegalArgumentException("文件不能为空"); } if (file.getSize() > 200 * 1024 * 1024) { // 200MB throw new IllegalArgumentException("文件大小不能超过200MB"); } // 2. 生成唯一文件名（防覆盖、防注入） String originalFilename = file.getOriginalFilename(); String extension = StringUtils.getFilenameExtension(originalFilename); String safeFilename = UUID.randomUUID().toString() + "." + extension; // 3. 创建存储路径 Path uploadPath = Paths.get(uploadDir); if (!Files.exists(uploadPath)) { Files.createDirectories(uploadPath); } Path targetPath = uploadPath.resolve(safeFilename); // 4. 流式写入（关键！避免内存溢出） try (InputStream inputStream = file.getInputStream(); OutputStream outputStream = Files.newOutputStream(targetPath)) { inputStream.transferTo(outputStream); } // 5. 记录元数据（模拟DB操作） FileRecord record = FileRecord.builder() .id(UUID.randomUUID().toString()) .originalName(originalFilename) .storedName(safeFilename) .size(file.getSize()) .bizId(bizId) .uploadTime(LocalDateTime.now()) .build(); // saveToDatabase(record); // 此处省略DB操作 log.info("文件上传成功: {} -> {}, bizId={}", originalFilename, safeFilename, bizId); return ResponseEntity.ok(new UploadResponse("success", record.getId(), safeFilename)); } catch (IOException e) { log.error("文件写入失败", e); throw new RuntimeException("文件保存失败", e); } } } @Data @Builder class UploadResponse { private String status; private String fileId; private String fileName; }

这个实现的亮点：

• inputStream.transferTo(outputStream)：Java 9+的零拷贝API，比IOUtils.copy更高效，内存占用恒定。
• UUID.randomUUID()生成文件名：彻底杜绝文件名注入（如../../../etc/passwd）和覆盖风险。
• @Value注入上传目录：方便Docker部署时通过环境变量FILE_UPLOAD_DIR覆盖。

4.3 业务系统（A端）完整实现

A端是核心枢纽，负责接收、校验、转发、状态同步。

@RestController @RequestMapping("/api/upload") @Slf4j public class UploadProxyController { @Autowired private WebClient webClient; // 使用WebClient进行异步流式转发 @Value("${file.server.url:http://file-server:8080}") private String fileServerUrl; @PostMapping public ResponseEntity<UploadResult> proxyUpload( @RequestParam("file") MultipartFile file, @RequestParam("bizId") String bizId, @RequestParam(value = "description", required = false) String description) { try { // 1. 业务校验（例如：检查bizId是否存在，用户是否有权限） validateBusinessContext(bizId); // 2. 构建转发请求体 MultipartBodyBuilder builder = new MultipartBodyBuilder(); builder.part("file", new InputStreamResource(file.getInputStream()) { @Override public String getFilename() { return file.getOriginalFilename(); } }); builder.part("bizId", bizId); if (StringUtils.hasText(description)) { builder.part("description", description); } // 3. 异步转发（WebClient天然支持流式） Mono<UploadResponse> responseMono = webClient.post() .uri(fileServerUrl + "/api/file/upload") .contentType(MediaType.MULTIPART_FORM_DATA) .bodyValue(builder.build()) .retrieve() .bodyToMono(UploadResponse.class) .timeout(Duration.ofMinutes(5)) // 全局超时5分钟 .onErrorResume(throwable -> { log.error("文件服务器调用失败，bizId={}", bizId, throwable); return Mono.error(new UploadException("文件服务器不可用，请稍后重试", throwable)); }); // 4. 阻塞等待结果（因Controller需同步返回） UploadResponse response = responseMono.block(); // 5. 成功后，可触发后续业务（如更新订单状态） handleUploadSuccess(bizId, response.getFileId()); log.info("上传代理成功: bizId={}, fileId={}", bizId, response.getFileId()); return ResponseEntity.ok(new UploadResult("success", response.getFileId(), response.getFileName())); } catch (UploadException e) { log.warn("上传代理失败: bizId={}, message={}", bizId, e.getMessage()); return ResponseEntity.status(500).body(new UploadResult("fail", null, e.getMessage())); } catch (Exception e) { log.error("上传代理未知错误", e); return ResponseEntity.status(500).body(new UploadResult("fail", null, "系统繁忙，请稍后重试")); } } private void validateBusinessContext(String bizId) { // 模拟：检查bizId对应的业务单据是否存在且状态合法 if (!bizId.startsWith("ORD-")) { throw new IllegalArgumentException("业务ID格式错误"); } // ... 更多校验逻辑 } private void handleUploadSuccess(String bizId, String fileId) { // 模拟：更新数据库，标记订单已上传附件 // updateOrderAttachment(bizId, fileId); } } @Data @Builder class UploadResult { private String status; private String fileId; private String message; } class UploadException extends RuntimeException { public UploadException(String message, Throwable cause) { super(message, cause); } }

关键点解析：

• WebClient替代RestTemplate：WebClient是响应式客户端，对流式上传支持更好，且内置timeout、retry等操作符，代码更简洁。
• builder.part("file", ...)：WebClient的MultipartBodyBuilder能正确构造multipart/form-data请求体，包括边界符（boundary）和Content-Disposition头。
• responseMono.block()：虽然WebClient是异步的，但Controller需同步返回，所以用block()阻塞。这没问题，因为block()只阻塞当前请求线程，不会影响其他请求，且我们配置了超时，不会无限等待。

4.4 前端调用示例（Vue3 + Axios）

前端只需向A端发起标准multipart请求，无需关心后端是直传还是代理。

<template> <div> <input type="file" @change="handleFileChange" /> <button @click="uploadFile" :disabled="isUploading">上传</button> <div v-if="uploadProgress > 0">上传进度: {{ uploadProgress }}%</div> </div> </template> <script setup> import { ref } from 'vue' import axios from 'axios' const file = ref(null) const isUploading = ref(false) const uploadProgress = ref(0) const handleFileChange = (e) => { file.value = e.target.files[0] } const uploadFile = async () => { if (!file.value) return isUploading.value = true uploadProgress.value = 0 const formData = new FormData() formData.append('file', file.value) formData.append('bizId', 'ORD-20231001-001') // 业务ID formData.append('description', '课程大纲V2') try { const response = await axios.post('/api/upload', formData, { headers: { 'Content-Type': 'multipart/form-data' }, onUploadProgress: (progressEvent) => { if (progressEvent.lengthComputable) { uploadProgress.value = Math.round( (progressEvent.loaded / progressEvent.total) * 100 ) } } }) console.log('上传成功:', response.data) } catch (error) { console.error('上传失败:', error) } finally { isUploading.value = false } } </script>

这个前端代码的亮点是onUploadProgress回调，它能实时获取上传进度，提升用户体验。Axios会自动设置Content-Type为multipart/form-data并带上正确的boundary，你无需手动拼接。

5. 常见问题与排查技巧实录：那些让你深夜加班的坑

5.1 问题速查表：症状、原因、解决方案

5.2 独家避坑技巧：来自血泪教训

技巧1：用curl命令行验证B端接口，绕过前端干扰
当上传失败时，先别急着改前端代码。用curl直接调用B端，排除前端问题：

curl -X POST "http://localhost:8080/api/file/upload" \ -F "file=@/path/to/test.pdf" \ -F "bizId=ORD-123"

如果curl成功，说明B端没问题，问题一定在A端或前端。这是我排查问题的第一步，能快速定位故障域。

技巧2：在A端添加“上传预检”接口，提前暴露配置问题
在A端加一个/api/upload/precheck接口，它不传文件，只检查：

• 能否连通B端（webClient.get().uri(...).exchange().block()）
• B端返回的Content-Type是否为application/json
• A端自身的max-file-size配置是否生效（MultipartConfigElement的getMaxFileSize()） 这样，前端在用户选择文件后，先调用预检，如果失败，立即提示“服务器配置异常”，而不是等到上传到一半才报错。

技巧3：B端存储路径必须用绝对路径，且赋予写权限
我曾在线上环境遇到一个诡异问题：B端日志显示“文件上传成功”，但/data/uploads目录下空空如也。排查3小时后发现，file.upload-dir配置的是相对路径uploads，而SpringBoot启动时的工作目录是/app，所以实际写入了/app/uploads，而运维监控的是/data/uploads。解决方案：所有路径配置必须用绝对路径，并在Dockerfile中显式RUN mkdir -p /data/uploads && chmod 755 /data/uploads。

技巧4：上传完成后，A端必须主动调用B端的“确认”接口
这是保障数据一致性的终极手段。A端转发成功后，不直接返回，而是再发一个GET请求到B端的/api/file/confirm/{fileId}。B端收到后，将该文件状态从PENDING改为CONFIRMED。如果确认失败（如网络超时），A端记录一条待办任务，后台定时重试。这样，即使A端在确认前宕机，文件也不会“悬空”。

我在某金融项目中实施了这个技巧，上线半年，0起因上传导致的数据不一致事故。它增加了1次HTTP调用，但换来的是数据强一致性，这笔账，怎么算都值。

6. 性能压测与优化：让系统扛住1000并发上传

6.1 压测方案设计：不只是看TPS

我们用JMeter进行压测，但指标不止于TPS（每秒事务数）。重点关注：

• 成功率：必须≥99.9%
• P99响应时间：≤ 30秒（含50MB文件上传）
• A端JVM内存增长：GC后应回落，无内存泄漏
• B端磁盘IO等待：iowait< 10%

压测脚本配置：

• 线程组：1000个线程，Ramp-Up Period 60秒（每秒启动16.6个用户）
• HTTP请求：POST/api/upload，Body Data为multipart/form-data，附带50MB随机文件
• 持续时间：10分钟

6.2 优化实战：从300 TPS到1200 TPS

初始压测结果惨不忍睹：300 TPS，成功率82%，P99时间127秒。我们按以下顺序优化：

Step 1：优化A端连接池
初始配置：maxTotal=20，defaultMaxPerRoute=2。1000并发下，连接池瞬间耗尽，大量请求排队等待连接。
优化后：maxTotal=200，defaultMaxPerRoute=50。TPS升至650，成功率92%。

Step 2：启用GZIP压缩
在A端和B端的application.yml中添加：

server: compression: enabled: true mime-types: text/html,text/xml,text/plain,application/json,application/xml,application/x-www-form-urlencoded

注意：不要压缩multipart/form-data，因为它是二进制，GZIP无效反而增加CPU开销。这个配置只压缩JSON响应体，减小网络传输量。TPS升至780。

Step 3：B端异步化文件存储
B端原本是同步写磁盘，transferTo阻塞线程。我们改为：

// B端Controller中 CompletableFuture.supplyAsync(() -> { try { Files.write(targetPath, file.getBytes()); // 或transferTo return "success"; } catch (Exception e) { throw new RuntimeException(e); } }, taskExecutor); // 使用自定义线程池

配合@Async和TaskExecutor，让文件写入不阻塞Web线程。TPS突破1000，P99降至22秒。

Step 4：A端启用响应式流背压
将A端的WebClient调用改为真正的响应式流：

// A端Controller中，不再用block() return webClient.post() .uri(fileServerUrl + "/api/file/upload") .bodyValue(builder.build()) .retrieve() .bodyToMono(UploadResponse.class) .map(response -> new UploadResult("success", response.getFileId(), response.getFileName())) .onErrorResume(throwable -> Mono.just(new UploadResult("fail", null, "上传失败"))) .flatMap(result -> { if ("success".equals(result.getStatus())) { return handleUploadSuccessAsync(bizId, result.getFileId()) .thenReturn(result); } return Mono.just(result); });

这需要Controller返回Mono<ResponseEntity<UploadResult>>，并添加@RestController注解。最终TPS稳定在1200，成功率99.99%，P99为18.3秒。

最后分享一个小技巧：压测时，务必在A端和B端都开启-XX:+PrintGCDetails，观察GC日志。如果Full GC频繁，说明内存配置不合理，需调整-Xms和-Xmx。我们最终将A端JVM参数设为-Xms2g -Xmx2g -XX:MetaspaceSize=256m，B端为-Xms1g -Xmx1g，完美匹配硬件资源。

我在实际项目中，就是靠着这套方法论，把跨服务器上传从一个“高危操作”变成了系统中最稳定的模块之一。它不炫技，但扎实；不取巧，但可靠。当你下次再看到“优雅实现”这个词，希望你能想到的，不是花哨的代码，而是对每一个配置项的敬畏，对每一次网络调用的审慎，以及对用户那几十秒等待的尊重。