企业官网建设流程全解析

1. 项目概述：为什么SpringBoot整合Gateway和Feign会成为高频踩坑区

“SpringBoot 整合Gateway、Feign采坑记录”这个标题，乍看像是一篇普通的技术笔记，但背后藏着微服务架构落地中最真实、最密集的痛感地带——它不是讲“怎么配通”，而是直指“配通之后为什么崩得悄无声息”。我带过三轮微服务重构项目，从某高校实验室的轻量级教学平台，到某公司中型电商后台系统，再到某跨平台IoT数据中台，只要用到Spring Cloud生态，几乎100%会在Gateway + Feign组合上卡住至少2天。不是报错不明确，就是现象反直觉：比如明明路由转发成功，下游服务日志里却收不到请求头；又或者Feign调用超时时间设成5秒，实际等了12秒才抛异常；再比如全局熔断配置生效了，但某个特定路径的Feign接口就是绕过熔断器……这些都不是配置遗漏，而是Spring Cloud各组件在责任边界模糊处的隐式耦合。

核心关键词“Gateway”“Feign”“SpringBoot”指向的是一个三层链路：客户端请求 → Spring Cloud Gateway（网关层）→ Feign Client（服务间调用层）。问题从来不出在单点，而出在它们交接的“缝隙”里——Gateway默认透传Header的策略与Feign的拦截器执行时机冲突；WebFlux响应式模型与Feign基于阻塞I/O的HTTP客户端存在线程上下文丢失；Hystrix（旧版）或Resilience4j（新版）的熔断作用域，在Gateway Filter链和Feign RequestInterceptor之间存在覆盖盲区。更关键的是，Spring Boot的自动配置（auto-configuration）在2.6.x升级到3.x后，对spring-cloud-starter-gateway和spring-cloud-openfeign的依赖收敛逻辑发生根本性变化，很多老项目沿用的@EnableFeignClients+@LoadBalanced RestTemplate混合写法，在新版本里会触发Bean创建顺序死锁。

适合谁来读？如果你正在做以下任何一件事，这篇内容就是为你写的：正在将单体SpringBoot应用拆分为微服务，且已引入网关做统一入口；正在调试Feign调用失败但日志无异常的“静默失败”问题；正在升级Spring Boot 2.x到3.x或Spring Cloud 2021.x到2022.x/2023.x；或者你刚在生产环境发现某个Feign接口偶发500，重启后消失，但监控里找不到对应错误堆栈。这不是理论文档，是我在某次凌晨三点排查订单服务调用库存服务超时问题时，把Gateway日志打到DEBUG级别、抓包分析Feign底层OkHttp连接池、翻了7个GitHub issue后整理出的实战清单。下面所有内容，都对应一个真实可复现的场景，参数值全部来自线上压测环境实测数据，不是Demo里的理想值。

2. 整体设计思路与方案选型逻辑：为什么必须放弃“默认配置思维”

2.1 网关与Feign的本质角色错位：不是管道，而是状态处理器

很多人把Gateway和Feign想象成两根“水管”：请求流进去，数据流出来。这是最大的认知偏差。实际上，Gateway是有状态的流量编排器，而Feign是有状态的HTTP客户端封装器。它们各自维护着独立的状态机，而Spring Boot的自动配置试图用同一套Bean生命周期去管理它们，必然导致状态同步失效。

举个典型例子：你在Gateway里用AddRequestHeader过滤器添加了X-Trace-ID，同时在Feign里用RequestInterceptor也添加了同名Header。你以为后者会覆盖前者？错。实际执行顺序是：Gateway Filter → 路由转发 → 下游服务收到Header → 下游服务用Feign调用其他服务。此时Feign的RequestInterceptor是在下游服务JVM内执行的，和Gateway完全无关。但开发者常误以为“网关加了，所有调用就都有”，结果在链路追踪里发现跨服务的Trace ID断裂。这就是角色错位——Gateway管的是“入站流量”，Feign管的是“出站流量”，它们之间没有天然的上下文传递通道。

所以我的设计原则第一条：显式声明状态传递契约。不依赖自动透传，而是用ReactiveRequestContext（WebFlux）或TransmittableThreadLocal（Servlet）在关键节点手动注入/提取。比如在Gateway的GlobalFilter里，把X-Trace-ID存入ServerWebExchange.getAttributes()；在Feign的RequestInterceptor里，从RequestContextHolder（Servlet环境）或ReactorContext（WebFlux环境）中读取并写入Header。这增加了代码量，但换来的是100%可预测的行为。

2.2 版本组合的硬性约束：Spring Boot 3.x下必须用Spring Cloud 2022.x+

这是血泪教训。某项目组在2023年Q2升级Spring Boot到3.1.0，但为了“兼容旧代码”，继续使用Spring Cloud 2021.0.3（即Edgware SR3）。结果出现诡异现象：Gateway能正常路由，但所有Feign接口返回503 Service Unavailable，且日志里没有任何错误。排查三天后发现，Spring Cloud 2021.x的spring-cloud-starter-gateway依赖的是spring-boot-starter-webflux2.7.x，而Spring Boot 3.1.0强制要求spring-boot-starter-webflux3.1.x，两者在ReactorNettyHttpClient的SSL配置类上存在方法签名不兼容。Maven虽然能resolve依赖，但运行时ClassLoader加载失败，导致NettyRoutingFilter初始化异常，被静默吞掉。

正确组合只有两种：

• Spring Boot 2.7.x + Spring Cloud 2021.x（Edgware）
• Spring Boot 3.0.x/3.1.x + Spring Cloud 2022.x（Kilburn）或2023.x（Leyton）

验证方法很简单：启动时看控制台是否输出Spring Cloud Gateway started，以及FeignClientFactoryBean是否注册成功。如果只看到Gateway启动日志，Feign相关Bean没打印，基本就是版本不匹配。我们团队现在强制执行“版本矩阵表”，放在Confluence首页，每次升级前先查表，避免重复踩坑。

2.3 熔断与限流的分层治理：Gateway做粗粒度防护，Feign做细粒度兜底

另一个常见误区是把所有熔断逻辑堆在Gateway。比如给所有路由配置HystrixCommand，超时时间统一设为3秒。这会导致两个问题：第一，下游服务实际处理时间可能只有200ms，但Gateway的3秒等待让前端用户多等2.8秒；第二，当某个Feign接口因数据库慢查询超时，Gateway熔断的是整个路由路径，而非具体接口，造成误伤。

我们的方案是分层治理：

• Gateway层：只做基础防护——单IP限流（100 QPS）、全局超时（5秒）、非法Header拦截（如X-Forwarded-For伪造检测）。用redis-rate-limiter实现分布式限流，Key设计为rate:ip:{#ip}，避免单点瓶颈。
• Feign层：针对每个@FeignClient单独配置熔断。比如订单服务调用支付服务，用@CircuitBreaker(name = "payment-service", fallbackFactory = PaymentFallbackFactory.class)，超时设为800ms，错误率阈值设为50%，半开探测间隔30秒。这样支付服务抖动时，只影响订单创建，不影响商品查询等其他Feign调用。

这种设计让故障隔离粒度从“服务级”细化到“接口级”，线上事故平均恢复时间（MTTR）从12分钟降到3分钟以内。

3. 核心细节解析与实操要点：那些文档里不会写的魔鬼参数

3.1 Gateway的Route Predicate与Filter执行顺序：比你想象的更严格

Gateway的路由匹配不是简单的“URL前缀匹配”，而是一个Predicate链的布尔运算。默认的Path=/api/**只是第一个Predicate，后面还可能有Header=X-Env, prod、Cookie=JSESSIONID, [a-zA-Z0-9]+等。关键在于：所有Predicate必须同时返回true，路由才匹配。但很多开发者在application.yml里写：

spring: cloud: gateway: routes: - id: user-service uri: lb://user-service predicates: - Path=/api/user/** - Header=X-Env, dev

然后在测试环境用curl -H "X-Env: prod"调用，发现404。原因？HeaderPredicate默认区分大小写，而X-Env在请求里是小写x-env。解决方案有两个：一是改用正则PredicateHeader=x-env, (?i)dev（(?i)开启忽略大小写）；二是全局配置spring.cloud.gateway.default-filters[0]=AddResponseHeader=X-Env, {env}，把环境信息注入响应头，避免在Predicate里校验。

更隐蔽的是Filter执行顺序。Gateway内置Filter有20+个，按Ordered接口排序，NettyRoutingFilter序号是10000，ModifyRequestBodyFilter是5000。如果你自定义Filter想修改请求体，必须确保序号小于5000，否则修改无效。我们曾遇到一个需求：网关需解密前端传来的AES加密参数。写了ModifyRequestBodyFilter，但序号设为10000，结果请求体始终是密文。查源码才发现，NettyRoutingFilter在10000执行，而ModifyRequestBodyFilter默认序号是Ordered.LOWEST_PRECEDENCE（2147483647），远在路由之后。最终解决方案是继承AbstractGatewayFilterFactory，重写apply方法时显式指定new OrderedGatewayFilter(..., 4999)。

提示：查看Filter执行顺序的最快方法是启动时加JVM参数-Dlogging.level.org.springframework.cloud.gateway=DEBUG，日志里会打印[ParallelFlux] | onSubscribe([SynchronousSink])及每个Filter的order值。

3.2 Feign的Encoder/Decoder陷阱：JSON序列化不是万能的

Feign默认用JacksonEncoder和JacksonDecoder，但这在微服务间传递复杂对象时极易翻车。比如下游服务返回一个Map<String, Object>，其中value可能是LocalDateTime、BigDecimal或自定义枚举。Jackson默认序列化LocalDateTime为{"year":2023,"month":10,...}这种对象格式，而前端期望的是ISO字符串"2023-10-15T14:30:00"。如果Feign客户端没配ObjectMapper，就会抛JsonMappingException。

但更致命的是BigDecimal精度丢失。Java里new BigDecimal("0.1")在JSON里序列化为0.1000000000000000055511151231257827021181583404541015625，因为二进制浮点数无法精确表示十进制小数。我们在线上遇到过支付金额显示异常，根源就是Feign用默认ObjectMapper序列化BigDecimal。

解决方案是自定义Feign.Builder：

@Bean public Feign.Builder feignBuilder() { ObjectMapper mapper = new ObjectMapper(); // LocalDateTime转ISO字符串 mapper.registerModule(new JavaTimeModule()); // BigDecimal保持精度，不转科学计数法 mapper.configure(JsonGenerator.Feature.WRITE_BIGDECIMAL_AS_PLAIN, true); // 禁用FAIL_ON_UNKNOWN_PROPERTIES，避免下游新增字段导致反序列化失败 mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); return Feign.builder() .encoder(new JacksonEncoder(mapper)) .decoder(new JacksonDecoder(mapper)); }

注意：FAIL_ON_UNKNOWN_PROPERTIES必须设为false。微服务迭代中，下游服务常会增加DTO字段，如果Feign客户端严格校验，会导致所有调用失败。这是“契约柔性”的体现，不是偷懒。

3.3 线程模型鸿沟：WebFlux的EventLoop vs Feign的阻塞IO

这是Spring Boot 3.x升级后最头疼的问题。Spring Cloud Gateway基于WebFlux，使用Netty的EventLoop线程处理请求；而Feign默认用ApacheHttpClient或OkHttpClient，是阻塞式IO，需要从EventLoop线程切换到普通线程池。如果不显式配置，所有Feign调用都会在EventLoop线程上阻塞，导致网关吞吐量暴跌。

验证方法：用jstack看线程栈，如果大量nioEventLoopGroup线程处于RUNNABLE但CPU占用低，基本就是阻塞IO卡住了。解决方案是强制Feign使用异步客户端，并配置独立线程池：

feign: okhttp: enabled: true client: config: default: connectTimeout: 2000 readTimeout: 5000 httpclient: disable-ssl-validation: true max-connections: 200 max-connections-per-route: 50

同时在代码里注入OkHttpClientBean：

@Bean public OkHttpClient okHttpClient() { return new OkHttpClient.Builder() .connectTimeout(2, TimeUnit.SECONDS) .readTimeout(5, TimeUnit.SECONDS) .connectionPool(new ConnectionPool(200, 5, TimeUnit.MINUTES)) .build(); }

这里ConnectionPool的maxIdleConnections=200必须和feign.httpclient.max-connections一致，否则连接池无法复用。我们实测过，未配置连接池时，100并发下Feign平均响应时间1200ms；配置后降到210ms，提升近6倍。

4. 实操过程与核心环节实现：从零搭建高可用组合的完整步骤

4.1 环境准备与依赖声明：Maven坐标必须精确到小版本

Spring Boot 3.1.0与Spring Cloud 2022.0.4（Kilburn SR4）的依赖声明，必须严格按以下方式书写，不能用<version>2022.0</version>这种模糊写法：

<properties> <java.version>17</java.version> <spring-boot.version>3.1.0</spring-boot.version> <spring-cloud.version>2022.0.4</spring-cloud.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>${spring-boot.version}</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- Gateway核心 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency> <!-- Feign核心 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> <!-- Resilience4j熔断（替代Hystrix） --> <dependency> <groupId>io.github.resilience4j</groupId> <artifactId>resilience4j-spring-cloud2</artifactId> <version>2.0.2</version> </dependency> </dependencies>

关键点：resilience4j-spring-cloud2的版本必须与Spring Cloud版本匹配。2022.x对应2.0.x，2023.x对应2.1.x。如果用错，@CircuitBreaker注解会失效，因为Resilience4jAutoConfiguration类路径不同。

4.2 Gateway核心配置：YAML里藏了5个必调参数

以下是生产环境验证过的application.yml核心片段，每个参数都有明确的业务含义：

spring: cloud: gateway: # 1. 全局超时：防止下游服务hang住网关线程 httpclient: connect-timeout: 2000 response-timeout: 5000 # 2. 路由缓存：避免每次请求都解析Predicate routes: - id: order-service uri: lb://order-service predicates: - Path=/api/order/** filters: # 3. 请求头清理：防止恶意Header穿透 - StripPrefix=1 - RemoveRequestHeader=Cookie - RemoveRequestHeader=Authorization # 4. 响应头增强：注入网关标识 - AddResponseHeader=X-Gateway-Version, v2.3.1 # 5. 重试机制：对GET请求自动重试2次（幂等操作） - name: Retry args: retries: 2 statuses: BAD_GATEWAY, SERVICE_UNAVAILABLE methods: GET backoff: firstBackoff=100, maxBackoff=500, factor=2, basedOnPreviousValue=false

参数详解：

• httpclient.response-timeout: 5000：这是网关等待下游服务响应的总时间，包括网络传输+下游处理。设太短（如1000ms）会导致正常慢查询被截断；设太长（如30000ms）会让前端长时间白屏。我们通过APM工具统计下游P95响应时间为1200ms，所以设为5000ms（留3倍缓冲）。
• RemoveRequestHeader=Cookie：禁用Cookie传递，因为微服务间调用不应依赖Session，所有认证信息应走JWT或OAuth2 Token。实测发现，某些老服务会因收到Cookie而触发Session创建，导致内存泄漏。
• RetryFilter的backoff参数：firstBackoff=100表示首次重试延迟100ms，maxBackoff=500限制最大延迟500ms，factor=2指每次延迟翻倍（100→200→400），basedOnPreviousValue=false确保延迟固定，不随网络波动变化。这样2次重试总耗时不超过100+200+400=700ms，远低于5秒超时。

4.3 Feign客户端标准写法：3个注解缺一不可

一个健壮的Feign客户端必须包含以下元素，少一个都可能在压测中暴雷：

@FeignClient( // 1. name指定服务名，必须与Eureka/Nacos注册名一致 name = "payment-service", // 2. configuration指定独立配置类，避免污染全局Feign配置 configuration = PaymentFeignConfig.class, // 3. path指定基础路径，避免每个方法都写完整URL path = "/api/payment" ) public interface PaymentFeignClient { @PostMapping("/create") @Headers("Content-Type: application/json") // 显式声明Content-Type Result<PaymentOrder> createOrder(@RequestBody PaymentOrderRequest request); @GetMapping("/status/{orderId}") Result<PaymentStatus> getStatus(@PathVariable("orderId") String orderId); } // 独立配置类 @Configuration public class PaymentFeignConfig { @Bean public Logger.Level feignLoggerLevel() { return Logger.Level.FULL; // 生产环境建议设为BASIC，DEBUG日志量太大 } @Bean public Retryer feignRetryer() { // 对5xx错误重试2次，间隔100ms return new Retryer.Default(100, TimeUnit.MILLISECONDS, 2); } }

关键细节：

• @Headers("Content-Type: application/json")必须显式声明。Feign默认不设Content-Type，某些下游服务（如Spring MVC）会因缺少此Header返回415 Unsupported Media Type。
• @PathVariable必须用@PathVariable("orderId")全写，不能简写为@PathVariable。Spring MVC 6.x后对此校验变严，简写会导致IllegalArgumentException: Name for argument type [java.lang.String] not available。
• Retryer配置在PaymentFeignConfig里，而不是全局配置。因为支付服务对重试敏感（重复扣款），而用户服务可以重试。分服务配置才能精准控制。

4.4 全局异常处理：统一捕获Gateway与Feign的“静默失败”

Gateway和Feign的异常体系完全不同：Gateway抛ResponseStatusException（如ResponseStatusException: 503 SERVICE_UNAVAILABLE），Feign抛FeignException（如feign.RetryableException: connect timed out executing POST ...）。如果用同一个@ControllerAdvice捕获，会漏掉一半错误。

我们的解决方案是双层拦截：

// 第一层：Gateway全局异常处理器 @RestControllerAdvice public class GatewayExceptionHandler { @ExceptionHandler(ResponseStatusException.class) public ResponseEntity<Map<String, Object>> handleResponseStatusException( ResponseStatusException ex, ServerWebExchange exchange) { Map<String, Object> body = new HashMap<>(); body.put("code", ex.getStatus().value()); body.put("message", ex.getReason()); body.put("timestamp", Instant.now().toString()); // 记录到ELK，包含traceId log.error("Gateway error: {}", ex.getMessage(), ex); return ResponseEntity.status(ex.getStatus()).body(body); } } // 第二层：Feign异常处理器（在Feign客户端所在服务中） @Component public class FeignErrorDecoder implements ErrorDecoder { private final ErrorDecoder defaultDecoder = new Default(); @Override public Exception decode(String methodKey, Response response) { try { if (response.status() == 500 || response.status() == 503) { // 解析下游服务返回的错误体 String body = Util.toString(response.body().asReader(StandardCharsets.UTF_8)); log.error("Feign call failed: method={}, status={}, body={}", methodKey, response.status(), body); return new ServiceException("下游服务异常：" + body); } } catch (IOException e) { log.error("Feign decode error", e); } return defaultDecoder.decode(methodKey, response); } }

这样，Gateway层的503错误会进入GatewayExceptionHandler，而Feign调用下游返回的500错误会被FeignErrorDecoder捕获并包装成ServiceException，再由服务自身的@ControllerAdvice处理。两层分离，确保所有异常都有迹可循。

5. 常见问题与排查技巧实录：线上事故还原与速查表

5.1 问题速查表：10个高频问题的定位路径与修复命令

5.2 真实事故还原：一次支付超时引发的全链路雪崩

2023年8月某日凌晨，某电商平台支付成功率从99.98%骤降至82%。监控显示：Gateway的gateway.requests指标突增，但gateway.routed指标几乎为0；Feign调用payment-service的createOrder接口超时率飙升至95%。初步判断是支付服务挂了，但登录服务器发现payment-service进程正常，CPU<20%，日志无ERROR。

我们按以下步骤排查：

1. 第一步：确认Gateway是否收到请求
   curl -v http://gateway/api/payment/create，响应时间12秒后返回503。说明请求到达Gateway，但未路由出去。

2. 第二步：检查路由配置
   curl http://gateway/actuator/gateway/routes，发现payment-service路由存在，uri为lb://payment-service。

3. 第三步：验证服务发现
   curl http://gateway/actuator/gateway/refresh后，再查路由，依然存在。接着查Nacos：payment-service有3个实例，健康状态均为UP。

4. 第四步：抓包分析网络层
   在Gateway服务器执行tcpdump -i any port 8080 -w gateway.pcap，用Wireshark打开，发现所有到payment-serviceIP的SYN包发出后，无SYN-ACK响应。说明网络不通。

5. 第五步：定位网络问题
   telnet payment-service-ip 8080超时。ping payment-service-ip成功。说明ICMP通，TCP不通。检查安全组规则，发现运维同学在凌晨更新了云防火墙策略，误删了8080端口放行规则。

6. 第六步：修复与验证
   运维紧急放行8080端口，telnet通了。但支付成功率仍为85%。继续查Feign日志，发现createOrder接口仍有超时。原因是OkHttpClient连接池里缓存了大量失败连接，需主动清理。执行curl -X POST http://gateway/actuator/refresh刷新配置，强制Feign重建连接池。

最终耗时47分钟。教训是：网络层故障必须前置监控。我们现在在Gateway加了/actuator/gateway/health端点，每30秒探测所有lb://服务的TCP连通性，失败时立即告警。

5.3 终极避坑清单：5条血换来的经验

1. 永远不要信任“自动配置”：Spring Boot的@ConditionalOnMissingBean看似智能，实则危险。比如FeignContext默认创建ObjectMapperBean，但如果你在@Configuration类里也声明了一个，就会因Bean冲突导致启动失败。解决方案：所有自定义Bean都加@Primary，或用@ConditionalOnMissingBean(name="xxx")精确限定。

2. 日志级别必须分层设置：Gateway的NettyRoutingFilter设DEBUG，Feign的feign.Logger设FULL，但org.springframework.web设WARN。否则日志量爆炸，磁盘10分钟写满。我们用Logback的<turboFilter>动态控制，根据X-Debug: true请求头临时提升日志级别。

3. Feign的@RequestBody参数必须是POJO，不能是Map：@PostMapping方法若写void create(@RequestBody Map<String, Object> data)，Feign会因无法推断泛型类型而序列化失败。必须封装为CreateRequest类，哪怕只有两个字段。

4. Gateway的StripPrefix过滤器只能用于Path Predicate：如果用Query或HeaderPredicate匹配路由，StripPrefix无效。此时要用RewritePath过滤器，正则表达式写为RewritePath=/api/(?<segment>.*), /$\{segment}。

5. 压测前必须关闭所有DEBUG日志：某次压测，logging.level.org.springframework.cloud.gateway=DEBUG开着，1000并发下日志写入速度达2GB/min，直接拖垮磁盘IO，导致Gateway假死。现在CI流程强制检查application.yml，禁止上线包含DEBUG日志配置。

6. 性能调优与扩展实践：从能用到好用的关键跨越

6.1 Gateway性能压测基准：如何设定合理的并发与超时阈值

我们用wrk对Gateway做压测，脚本如下：

# 测试命令 wrk -t12 -c400 -d30s --latency http://localhost:8080/api/order/create # 关键参数解释： # -t12：12个线程（模拟12核CPU） # -c400：保持400个HTTP连接（模拟高并发连接池） # -d30s：持续30秒 # --latency：记录详细延迟分布

压测结果需关注三个黄金指标：

• 吞吐量（RPS）：稳定在3500+ RPS才算合格（对应10万日活系统）
• P95延迟：必须≤200ms（用户感知无卡顿）
• 错误率：≤0.1%（99.9%可用性）

当P95延迟超标时，优先调优以下参数：

• spring.cloud.gateway.httpclient.max-connections=1000（默认200）
• spring.cloud.gateway.httpclient.max-connections-per-route=200（默认50）
• spring.cloud.gateway.httpclient.connect-timeout=1000（从2000ms降为1000ms，逼下游优化）

注意：max-connections不能无限制增大，需按公式计算：max-connections ≤ (可用内存MB × 1024 × 1024) / (每个连接内存KB)。实测每个Netty连接约占用128KB，所以16GB内存服务器最大设为16×1024×1024/128≈131072，但我们保守设为5000，留足余量。

6.2 Feign连接池深度调优：OkHttp的5个核心参数

OkHttp连接池是Feign性能瓶颈的主因。以下是生产环境实测最优参数：

@Bean public OkHttpClient okHttpClient() { return new OkHttpClient.Builder() // 1. 连接超时：建立TCP连接的最大时间 .connectTimeout(1, TimeUnit.SECONDS) // 2. 读取超时：从socket读取数据的最大时间 .readTimeout(3, TimeUnit.SECONDS) // 3. 写入超时：向socket写入数据的最大时间 .writeTimeout(3, TimeUnit.SECONDS) // 4. 连接池：最大空闲连接数，必须≥feign.httpclient