企业官网建设流程全解析

1. 从RestTemplate到RestClient：一次迟到的“拨乱反正”

如果你和我一样，是从Spring 3.x甚至更早版本一路用过来的老开发者，那么对RestTemplate这个名字一定感情复杂。它曾是Spring生态中调用HTTP服务的绝对主力，简单、直接，但也因其“重量级”和略显过时的设计而备受诟病。尤其是在微服务、云原生和响应式编程大行其道的今天，一个阻塞式的、基于模板模式的客户端，总让人觉得与时代有些脱节。Spring Boot 3.2带来的全新RestClient，在我看来，不是一次简单的API更新，而是一次迟到的、对HTTP客户端使用体验的“拨乱反正”。它没有选择另起炉灶搞一套全新的异步或响应式API（那有WebClient），而是精准地瞄准了那些依然需要同步、阻塞式调用的场景，用一套更现代、更流畅、更符合Java开发者直觉的API，重新定义了同步HTTP客户端该有的样子。这就像给你的旧车换上了一台更高效、更平顺的新发动机，驾驶体验提升立竿见影，但操作习惯几乎无需改变。

2. RestClient核心设计哲学：流畅（Fluent）与不可变（Immutable）

要理解RestClient，首先要抓住它的两个核心设计哲学：流畅API和不可变构建。这直接决定了它的使用方式和优势所在。

2.1 告别链式“污染”：不可变构建器的优势

RestTemplate时代，我们经常这样写代码：

RestTemplate template = new RestTemplate(); template.setMessageConverters(...); template.setInterceptors(...); // 然后使用template进行各种请求

这种方式的问题是，RestTemplate实例本身是可变的（mutable）。如果你在某个地方修改了它的配置（比如添加了一个全局拦截器），那么所有使用这个RestTemplate的地方都会受到影响。在多线程环境或复杂的应用结构中，这很容易引发难以追踪的配置污染问题。

RestClient彻底改变了这一点。它采用了建造者模式（Builder Pattern）来创建客户端，并且构建出的RestClient实例是不可变的（Immutable）。

// 创建一个基础配置的、不可变的RestClient RestClient baseClient = RestClient.builder() .baseUrl("https://api.example.com") .defaultHeader("User-Agent", "MyApp/1.0") .build(); // 基于baseClient，创建一个添加了认证头的新客户端，原baseClient不受影响 RestClient authClient = baseClient.mutate() .defaultHeader("Authorization", "Bearer new-token") .build();

这里的mutate()方法会返回一个新的建造者，让你在现有配置基础上进行修改，最终生成一个全新的RestClient实例。原来的baseClient配置纹丝不动。这种不可变性带来了巨大的好处：线程安全和配置隔离。你可以放心地创建具有不同用途（如对内服务、对外API、带特殊认证等）的客户端实例，而不用担心它们相互干扰。

2.2 行云流水的调用体验：流畅API详解

流畅API（Fluent API）意味着方法调用可以像链条一样连接下去，让代码读起来就像一句完整的句子。RestClient将这一点发挥到了极致。

一个完整的GET请求示例如下：

String result = restClient.get() .uri("/users/{id}", 123) // 设置URI和路径变量 .header("X-Custom-Header", "value") // 设置请求头 .accept(MediaType.APPLICATION_JSON) // 设置Accept头 .retrieve() // 执行请求并准备检索响应 .body(String.class); // 将响应体转换为指定类型

让我们拆解这个链条：

1. restClient.get(): 指定HTTP方法，返回一个RequestHeadersUriSpec对象，代表一个待配置的请求。
2. .uri(...): 设置请求路径。支持路径变量（{id}）和UriBuilder的完整功能。
3. .header(...)/.accept(...): 设置请求头。这些方法可以链式调用多次。
4. .retrieve():关键方法。它触发实际的HTTP调用，并返回一个ResponseSpec对象，用于处理响应。注意，此时网络请求已经发生。
5. .body(String.class): 从ResponseSpec中提取响应体，并尝试用配置的HttpMessageConverter将其转换为指定的Java类型（这里是String）。

这种链式调用不仅写起来顺畅，更重要的是，它通过类型系统清晰地定义了每个阶段能做什么（比如，只有在.retrieve()之后才能处理响应），减少了误用的可能性。

注意：.retrieve()方法是同步且阻塞的。它会一直等待直到收到完整的HTTP响应（或超时）。这也是RestClient与异步的WebClient的核心区别之一。RestClient专注于简化同步阻塞调用，如果你需要非阻塞或响应式编程，WebClient仍然是更佳选择。

3. 实战：从基础调用到高级特性全解析

理解了设计哲学，我们进入实战环节。我将通过一个模拟的用户服务API，展示RestClient从入门到精通的完整使用路径。

3.1 基础配置与实例创建

首先，在Spring Boot 3.2项目中，你不需要引入额外依赖，spring-boot-starter-web已经包含了RestClient。

创建RestClient有多种方式，适应不同场景：

方式一：使用建造者从头构建

import org.springframework.web.client.RestClient; @Configuration public class AppConfig { @Bean public RestClient myRestClient() { return RestClient.builder() .baseUrl("https://jsonplaceholder.typicode.com") // 基础URL .defaultHeader("Accept", MediaType.APPLICATION_JSON_VALUE) // 默认头 .defaultStatusHandler(HttpStatusCode::is4xxClientError, (request, response) -> { // 默认的4xx错误处理 throw new MyClientException("Client error: " + response.getStatusCode()); }) .requestInterceptor((request, body, execution) -> { // 请求拦截器，可用于日志、计量等 log.info("Sending request to: {}", request.getURI()); return execution.execute(request, body); }) .build(); } }

方式二：从RestTemplate平滑迁移如果你有现有的RestTemplate，并且配置了复杂的消息转换器或拦截器，可以快速转换：

RestTemplate oldTemplate = ... // 你现有的RestTemplate RestClient restClient = RestClient.builder(oldTemplate).build();

RestClient.builder(RestTemplate)会拷贝RestTemplate的ClientHttpRequestFactory、消息转换器列表和拦截器，实现零成本迁移。

方式三：使用Spring Boot的自动配置Spring Boot 3.2为RestClient提供了自动配置。你可以在application.yml中配置：

spring: restclient: base-url: https://api.example.com default-headers: accept: application/json user-agent: MySpringBootApp

然后通过@Autowired注入一个预配置的RestClient实例。这种方式最适合简单的、全局统一的HTTP客户端需求。

3.2 各种HTTP方法的调用模式

RestClient支持所有标准的HTTP方法，调用模式高度一致。

GET 请求：获取资源

// 1. 获取简单响应体 User user = restClient.get() .uri("/users/{id}", userId) .retrieve() .body(User.class); // 2. 获取完整的ResponseEntity，包含状态码、头信息等 ResponseEntity<User> responseEntity = restClient.get() .uri("/users/{id}", userId) .retrieve() .toEntity(User.class); // 注意是 toEntity // 3. 处理可能为空的响应（404 Not Found） User user = restClient.get() .uri("/users/{id}", 9999) // 假设ID不存在 .retrieve() .onStatus(status -> status == HttpStatus.NOT_FOUND, (request, response) -> { // 专门处理404，返回null而不是抛异常 return; }) .body(User.class); // 如果404，这里body为null

POST 请求：创建资源

// 1. 发送JSON体，并期望返回创建的对象 User newUser = new User("John Doe", "john@example.com"); User createdUser = restClient.post() .uri("/users") .contentType(MediaType.APPLICATION_JSON) .body(newUser) // 自动使用Jackson序列化 .retrieve() .body(User.class); // 2. 发送表单数据 MultiValueMap<String, String> formData = new LinkedMultiValueMap<>(); formData.add("username", "john"); formData.add("password", "secret"); String result = restClient.post() .uri("/login") .contentType(MediaType.APPLICATION_FORM_URLENCODED) .body(formData) .retrieve() .body(String.class);

PUT 与 PATCH 请求：更新资源

// PUT - 替换整个资源 User updatedUser = new User("Jane Doe", "jane@example.com"); restClient.put() .uri("/users/{id}", userId) .contentType(MediaType.APPLICATION_JSON) .body(updatedUser) .retrieve() // PUT请求可能没有响应体，但retrieve()仍会触发请求并检查状态 .toBodilessEntity(); // 明确表示不期待响应体 // PATCH - 部分更新资源（需服务端支持） Map<String, Object> patchData = Map.of("email", "new-email@example.com"); restClient.patch() .uri("/users/{id}", userId) .contentType(MediaType.APPLICATION_JSON) .body(patchData) .retrieve() .toBodilessEntity();

DELETE 请求：删除资源

// 简单删除 restClient.delete() .uri("/users/{id}", userId) .retrieve() .toBodilessEntity(); // 带条件的删除（例如，匹配ETag） restClient.delete() .uri("/users/{id}", userId) .header("If-Match", "\"some-etag-value\"") .retrieve() .toBodilessEntity();

3.3 请求与响应的精细化控制

RestClient提供了细粒度的控制能力，远超RestTemplate的简单exchange方法。

请求头（Headers）的灵活设置

String result = restClient.get() .uri("/data") .header("Authorization", "Bearer " + token) .header("X-Request-ID", UUID.randomUUID().toString()) // 链式添加多个头 .accept(MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML) // 设置Accept，服务端可择一返回 .ifNoneMatch("\"v1.0\"") // 条件请求：如果匹配ETag则返回304 .ifModifiedSince(Instant.now().minus(Duration.ofDays(1))) // 条件请求 .retrieve() .body(String.class);

URI构建的多种姿势

// 1. 简单路径 .uri("/api/v1/users") // 2. 使用路径变量 (推荐，自动编码) .uri("/users/{id}/posts/{postId}", userId, postId) // 3. 使用URI模板和Map Map<String, Object> uriVars = Map.of("id", userId, "type", "admin"); .uri("/users/{id}/type/{type}", uriVars) // 4. 使用UriBuilder进行复杂构建 .uri(uriBuilder -> uriBuilder .path("/search") .queryParam("q", searchTerm) .queryParam("page", page) .queryParam("size", size) .build())

响应处理的三种模式.retrieve()方法返回的ResponseSpec提供了三种主要的响应处理方式：

1. .body(Class<T>): 最常用，只关心成功时的响应体。遇到4xx/5xx状态码会抛出RestClientException子类。
2. .toEntity(Class<T>): 获取完整的ResponseEntity<T>，包含状态码、头信息和响应体。同样，遇到错误状态码会抛异常。
3. .toBodilessEntity(): 当你只关心请求是否成功（如DELETE，PUT），不期待响应体时使用。

错误处理（Status Handlers）的进化这是RestClient相比RestTemplate的一大改进。错误处理更加声明式和集中化。

// 方式1：在创建RestClient时定义默认错误处理器（全局） RestClient client = RestClient.builder() .baseUrl("https://api.example.com") .defaultStatusHandler(HttpStatusCode::is4xxClientError, (request, response) -> { throw new MyCustomClientErrorException(response.getStatusCode(), "Client error occurred"); }) .defaultStatusHandler(HttpStatusCode::is5xxServerError, (request, response) -> { throw new MyCustomServerErrorException(response.getStatusCode(), "Server is down"); }) .build(); // 方式2：在单次请求中覆盖或添加特定的错误处理器（局部） User user = client.get() .uri("/users/{id}", id) .retrieve() .onStatus(status -> status == HttpStatus.NOT_FOUND, (request, response) -> { // 专门处理404，例如返回一个默认值或记录日志 log.warn("User with id {} not found", id); // 注意：这里不抛异常，retrieve()会继续执行，body()可能返回null }) .onStatus(status -> status == HttpStatus.FORBIDDEN, (request, response) -> { // 处理403，例如抛出一个业务特定的异常 throw new InsufficientPrivilegeException("No permission to access user"); }) .body(User.class); // 如果404被处理且未抛异常，这里可能为null

这种设计将错误处理逻辑从业务代码中剥离，使得核心业务流（获取用户）更加清晰。你可以根据不同的API、不同的错误码，定义非常精细的恢复或失败策略。

3.4 消息转换器（Message Converters）与拦截器（Interceptors）

RestClient继承了Spring强大的HttpMessageConverter机制，并提供了灵活的拦截器接口。

消息转换器的配置与使用默认情况下，RestClient会使用Spring上下文中的一组默认消息转换器（如MappingJackson2HttpMessageConverter用于JSON）。你也可以自定义：

RestClient customClient = RestClient.builder() .messageConverters(converters -> { // 清除默认的，添加自己的 converters.clear(); // 添加一个支持JSON的Jackson转换器，并配置属性 ObjectMapper mapper = new ObjectMapper(); mapper.registerModule(new JavaTimeModule()); mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); converters.add(new MappingJackson2HttpMessageConverter(mapper)); // 添加String转换器 converters.add(new StringHttpMessageConverter()); }) .build();

当你使用.body(Object)发送请求或.body(Class<T>)接收响应时，会自动选择合适的转换器。

拦截器：实现横切关注点拦截器是RestClient的另一个强大功能，用于在请求发出前和响应返回后执行通用逻辑。

RestClient loggedClient = RestClient.builder() .requestInterceptor((request, body, execution) -> { // 1. 请求前：记录日志、添加签名、计量开始 long startTime = System.nanoTime(); String requestId = UUID.randomUUID().toString(); request.getHeaders().add("X-Request-ID", requestId); log.info("Outgoing request [{}]: {} {}", requestId, request.getMethod(), request.getURI()); // 2. 执行请求 ClientHttpResponse response = execution.execute(request, body); // 3. 响应后：记录耗时、处理通用错误 long duration = (System.nanoTime() - startTime) / 1_000_000; log.info("Incoming response [{}]: {} in {} ms", requestId, response.getStatusCode(), duration); // 4. 可以在这里包装response，甚至重试逻辑（需谨慎） return response; }) // 可以添加多个拦截器，按添加顺序执行 .requestInterceptor(new BasicAuthenticationInterceptor("user", "password")) .build();

常见的拦截器用途包括：

• 认证：自动添加Authorization头。
• 日志：记录所有请求和响应的摘要信息。
• 链路追踪：注入Trace ID、Span ID。
• 重试：实现简单的重试机制（注意：复杂的重试建议用RetryTemplate或Resilience4j等专业库）。
• 指标收集：记录请求耗时、状态码分布等。

4. 避坑指南与性能调优实战

在实际项目中使用RestClient，你可能会遇到一些“坑”。下面是我从实际项目中总结的经验和解决方案。

4.1 连接池配置：避免性能瓶颈的隐形杀手

默认情况下，RestClient底层使用的SimpleClientHttpRequestFactory（或基于Apache HttpClient、OkHttp等）可能没有配置连接池，或者配置不合理，这在并发请求下会成为性能瓶颈。

问题场景：你的服务需要高频调用下游某个API，QPS达到几百。使用默认配置的RestClient后，发现经常出现连接超时、响应缓慢，监控显示TCP连接数不断创建和销毁，开销巨大。

解决方案：为RestClient配置一个带连接池的ClientHttpRequestFactory。这里以Apache HttpClient 5为例：

1. 添加依赖（如果尚未引入）：

   <dependency> <groupId>org.apache.httpcomponents.client5</groupId> <artifactId>httpclient5</artifactId> </dependency>

2. 配置连接池和HttpClient：

   @Configuration public class RestClientConfig { @Bean public RestClient highPerformanceRestClient() { // 1. 创建连接池管理器 PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager(); connectionManager.setMaxTotal(200); // 整个连接池最大连接数 connectionManager.setDefaultMaxPerRoute(50); // 每个路由（目标主机）默认最大连接数 // 可以针对特定主机设置 // connectionManager.setMaxPerRoute(new HttpRoute(new HttpHost("api.slow.com")), 20); // 2. 配置请求超时、连接超时等 RequestConfig requestConfig = RequestConfig.custom() .setConnectTimeout(Timeout.ofSeconds(5)) // 连接超时 .setResponseTimeout(Timeout.ofSeconds(10)) // 响应超时 .build(); // 3. 构建HttpClient CloseableHttpClient httpClient = HttpClients.custom() .setConnectionManager(connectionManager) .setDefaultRequestConfig(requestConfig) .evictExpiredConnections() // 驱逐过期连接 .evictIdleConnections(TimeValue.ofMinutes(1)) // 驱逐空闲连接 .build(); // 4. 使用HttpComponentsClientHttpRequestFactory ClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory(httpClient); // 5. 构建RestClient return RestClient.builder() .requestFactory(requestFactory) .baseUrl("https://api.example.com") .build(); } }

   关键参数解析：

   • setMaxTotal(200): 连接池总共最多持有200个连接。根据你的应用线程数和下游服务能力调整。
   • setDefaultMaxPerRoute(50): 对于同一个host:port（路由），最多同时有50个连接。这是防止对单一服务连接数过多。
   • setConnectTimeout: 建立TCP连接的超时时间。
   • setResponseTimeout: 从请求发出到收到完整响应的超时时间（含数据传输）。
   • evictIdleConnections: 定期清理空闲连接，释放资源。

3. 将配置好的RestClient注入使用：

   @Service public class UserService { private final RestClient restClient; public UserService(@Qualifier("highPerformanceRestClient") RestClient restClient) { this.restClient = restClient; } // ... 使用restClient进行调用 }

实测心得：连接池配置没有银弹，需要根据实际压测结果调整。一个常见的起始点是MaxPerRoute设置为你的应用最大并发线程数，MaxTotal设置为MaxPerRoute * 下游服务数量。务必监控生产环境的连接池状态（如活跃连接数、空闲连接数、等待队列长度）。

4.2 超时控制：区分连接、读取与总超时

超时配置不当是线上故障的常见原因。RestClient本身不直接设置超时，它依赖于底层的ClientHttpRequestFactory。

误区：很多人只设置一个“超时时间”，但HTTP请求涉及多个阶段，需要分别控制。

正确配置（以Apache HttpClient 5为例）：

RequestConfig requestConfig = RequestConfig.custom() .setConnectTimeout(Timeout.ofSeconds(3)) // 连接超时：与服务器建立TCP连接的最长时间 .setConnectionRequestTimeout(Timeout.ofSeconds(1)) // 从连接池获取连接的超时时间 .setResponseTimeout(Timeout.ofSeconds(10)) // 响应超时：从连接建立成功到收到完整响应包的最长时间 .build();

• 连接超时：网络不通、服务器端口未开放时触发。应设置较短（如2-5秒）。
• 连接请求超时：从连接池获取连接等待时间。如果连接池耗尽，请求会在此处等待。通常设置很短（1-2秒），超时立即失败，避免长时间阻塞。
• 响应超时：服务器处理过慢或网络传输慢时触发。根据下游API的SLA（服务等级协议）设置（如5-30秒）。

在RestClient中统一处理超时异常：

RestClient client = RestClient.builder() .requestFactory(...) // 使用配置了超时的factory .defaultStatusHandler(HttpStatusCode::is5xxServerError, (request, response) -> { // 处理服务器错误 }) .build(); // 使用try-catch捕获可能的超时异常（通常是RestClientException的子类） try { client.get() .uri("/slow-api") .retrieve() .body(String.class); } catch (ResourceAccessException e) { // RestClientException的子类，通常包装了IO超时等异常 if (e.getCause() instanceof SocketTimeoutException) { log.error("读取响应超时", e); // 执行降级逻辑，如返回缓存、默认值 return fallbackData; } else if (e.getCause() instanceof ConnectTimeoutException) { log.error("连接服务器超时", e); throw new ServiceUnavailableException("下游服务不可达"); } throw e; }

4.3 响应式编程混用下的线程阻塞风险

这是一个在Spring WebFlux（响应式）项目中容易踩的坑。

问题场景：你的应用是使用Spring WebFlux构建的响应式应用，但某个服务需要调用一个只提供同步HTTP接口的下游系统。你直接在@Service的某个方法中使用了RestClient进行阻塞调用。

@Service public class ReactiveUserService { private final RestClient restClient; private final ReactiveUserRepository reactiveRepo; public Mono<User> getUserWithExternalData(String userId) { // 从响应式仓库获取用户 return reactiveRepo.findById(userId) .flatMap(user -> { // 错误！在响应式链中进行阻塞调用 ExternalData data = restClient.get() // 这是一个阻塞操作！ .uri("/external-api/data/{id}", user.getExternalId()) .retrieve() .body(ExternalData.class); user.setExternalData(data); return Mono.just(user); }); } }

在响应式编程中，所有操作都应在非阻塞的线程（如Netty的EventLoop线程）上执行。上述代码中的restClient.get().retrieve()是阻塞的，它会挂起当前线程直到收到响应。如果这个阻塞操作发生在EventLoop线程上，会严重拖慢整个应用的响应能力，甚至导致线程饥饿。

解决方案：将阻塞调用调度到专门的、用于阻塞任务的线程池上。

@Service public class ReactiveUserService { private final RestClient restClient; private final ReactiveUserRepository reactiveRepo; private final Scheduler blockingScheduler; // 专门用于阻塞任务的调度器 public ReactiveUserService(RestClient restClient, ReactiveUserRepository reactiveRepo) { this.restClient = restClient; this.reactiveRepo = reactiveRepo; // 创建一个有边界的弹性线程池，专门处理阻塞IO this.blockingScheduler = Schedulers.boundedElastic(); } public Mono<User> getUserWithExternalData(String userId) { return reactiveRepo.findById(userId) .flatMap(user -> Mono.fromCallable(() -> { // 将阻塞调用包装在Callable中 return restClient.get() .uri("/external-api/data/{id}", user.getExternalId()) .retrieve() .body(ExternalData.class); }) .subscribeOn(blockingScheduler) // **关键**：在阻塞调度器上执行 .doOnNext(data -> user.setExternalData(data)) .thenReturn(user) // 转换回User的Mono ); } }

核心要点：

1. Mono.fromCallable(): 将阻塞的RestClient调用包装成一个Callable。
2. .subscribeOn(blockingScheduler): 指定这个Callable在blockingScheduler这个专门的线程池上执行，从而不阻塞响应式主线程。
3. Schedulers.boundedElastic(): Reactor提供的弹性线程池，适用于阻塞任务。它会根据需要创建线程，但有上限，防止创建过多线程。

4.4 文件上传与下载：处理流式数据

RestClient同样支持流式数据的传输，比如文件上传和下载。

文件上传（Multipart Form Data）：

// 假设要上传一个文件和一个JSON字段 Resource fileResource = new FileSystemResource("/path/to/file.txt"); MultiValueMap<String, Object> parts = new LinkedMultiValueMap<>(); parts.add("file", fileResource); // 文件部分 parts.add("metadata", Map.of("name", "myfile", "type", "text")); // JSON部分，会自动序列化 String response = restClient.post() .uri("/upload") .contentType(MediaType.MULTIPART_FORM_DATA) // 关键：设置Content-Type .body(parts) .retrieve() .body(String.class);

Spring会自动处理MultiValueMap，将文件部分编码为multipart/form-data格式，并将JSON对象序列化为表单字段。

大文件下载（流式处理到磁盘）：

restClient.get() .uri("/download/large-file.zip") .accept(MediaType.APPLICATION_OCTET_STREAM) .retrieve() .toEntity(Resource.class) // 获取ResponseEntity<Resource> .subscribe(responseEntity -> { Resource resource = responseEntity.getBody(); try (InputStream inputStream = resource.getInputStream(); FileOutputStream outputStream = new FileOutputStream("/local/path/file.zip")) { // 使用缓冲区流式拷贝，避免内存溢出 byte[] buffer = new byte[8192]; int bytesRead; while ((bytesRead = inputStream.read(buffer)) != -1) { outputStream.write(buffer, 0, bytesRead); } } catch (IOException e) { log.error("Failed to download file", e); } });

对于超大文件，使用.toEntity(Resource.class)获取响应体作为Resource，然后通过流式IO写入本地文件，这是最安全、最省内存的方式。千万不要用.body(String.class)或.body(byte[].class)去接收大文件。

5. 与RestTemplate、WebClient的深度对比与选型建议

Spring生态现在有三个主要的HTTP客户端：RestTemplate、WebClient和RestClient。如何选择？

选型决策树：

1. 你的应用是响应式的吗？（使用Spring WebFlux）

   • 是-> 毫不犹豫，选择WebClient。它是响应式栈的原生选择。
   • 否-> 进入第2步。

2. 你的应用是传统的Servlet应用吗？（使用Spring MVC）

   • 是，且是新项目或重大重构-> 选择RestClient。它提供了现代、流畅的API，错误处理更友好，是RestTemplate的完美替代品。
   • 是，但已有大量RestTemplate代码，改动成本高-> 可以暂时继续使用RestTemplate，但新模块建议用RestClient。长远看，RestTemplate终将被淘汰。
   • 否，是其他类型应用（如批处理、命令行工具）-> 选择RestClient。它的同步阻塞模型更简单直观，适合脚本或顺序任务。

迁移策略： 从RestTemplate迁移到RestClient相对平滑，因为底层基础设施相同。主要工作是重写调用代码的API。你可以利用RestClient.builder(oldTemplate)快速创建一个具有相同配置的RestClient实例，然后逐步替换各个调用点。

我个人在将团队的一个老项目从RestTemplate迁移到RestClient后，最直观的感受是代码可读性大幅提升，错误处理逻辑更加集中和清晰，再也不用在业务代码里到处写try-catch来处理不同的HTTP状态码了。对于仍在维护传统Spring MVC项目的团队来说，RestClient是技术栈更新一个非常好的切入点，它能带来立竿见影的代码质量改善，而迁移成本却可控。