服务发现失败时，eureka.client.fetch-registry和register-with-eureka必须配对检查，因二者是协作关系：前者控制是否拉取服务列表，后者控制是否注册自身，错配将导致注册失败或无法发现服务。
服务发现失败时，eureka.client.fetch-registry 和 eureka.client.register-with-eureka 为什么必须配对检查
微服务启动后注册不到 Eureka Server，或无法拉取服务列表，八成是这两个布尔配置没对齐。它们不是独立开关，而是协作关系：fetch-registry 控制是否从 Server 拉取服务列表（影响 DiscoveryClient 的可用实例），register-with-eureka 控制是否把自己注册上去。
常见错误场景：
- 网关服务设了
register-with-eureka: false（合理，不希望被其他服务调用），但忘了关fetch-registry: true（必须开，否则找不到下游服务） - Eureka Server 自身也启用了 client，默认会尝试注册自己——若未在
eureka.client.service-url.defaultZone中指向其他节点，就会报Cannot execute request on any known server - 本地调试时禁用了注册（
register-with-eureka: false），却仍依赖@LoadBalanced RestTemplate，结果ServiceInstanceListSupplier返回空列表，调用直接抛IllegalStateException: No instances available
@LoadBalanced RestTemplate 在 Spring Cloud 2020+ 之后为什么经常失效
Spring Cloud 2020.0.0（即 Ilford 版本）起，RestTemplate 的负载均衡能力不再由 LoadBalancerAutoConfiguration 全自动装配，而是依赖 BlockingLoadBalancerClient + ServiceInstanceListSupplier，且默认只支持 Reactor 环境下的 WebClient。若项目没显式引入 spring-cloud-starter-loadbalancer，@LoadBalanced 注解将静默失效——不会报错，但请求始终发往 localhost:8080。
修复方式：
立即学习“Java免费学习笔记（深入）”；
- 确认依赖中存在
spring-cloud-starter-loadbalancer（不是spring-cloud-starter-netflix-ribbon，Ribbon 已废弃） - 检查是否误删了
@Bean定义：旧版常写@Bean @LoadBalanced RestTemplate restTemplate()，新版仍需保留该 Bean 声明，否则自动配置不触发 - 若使用 OpenFeign，要确保
spring-cloud-starter-openfeign版本 ≥ 3.0.0，且feign.loadbalancer.enabled=true（默认为 true，但显式声明更稳妥）
Consul 作为注册中心时，spring.cloud.consul.discovery.health-check-path 配置不对会导致服务持续被下线
Consul 默认通过 HTTP GET 请求服务的 /actuator/health 端点判断健康状态。如果 Spring Boot Actuator 版本 ≥ 3.x，/actuator/health 默认返回 200，但 Consul 发起的请求头不含 Accept: application/vnd.spring-boot.actuator.v3+json，导致响应体为空或 406 —— Consul 将其视为健康检查失败，反复踢出服务。
解决路径只有两条：
- 降级 Actuator 版本（不推荐）
- 改用兼容路径：在
application.yml中显式指定spring.cloud.consul.discovery.health-check-path: /actuator/health/showdetails（需配合 Actuator 3.x 的management.endpoint.health.show-details=always） - 或更彻底：关闭 Consul 自动健康检查，改用 TTL 模式——设置
spring.cloud.consul.discovery.health-check-ttl: 30s，并在服务内定时调用ConsulClient#passTTL
Nacos 2.x 中 nacos.naming.cache.dir 不生效的真正原因
这个配置项在 Nacos 2.x 客户端（com.alibaba.cloud:spring-cloud-starter-alibaba-nacos-discovery:2.2.10-RC1 及以上）中已被完全忽略。Nacos 客户端内部改用内存缓存 + 本地磁盘映射（~/.nacos/naming/ 下的 JSON 文件），但该路径由客户端硬编码决定，不受 Spring Boot 配置控制。
如果你看到日志里反复出现 fail to update cache from remote server，或服务列表更新延迟明显，并非缓存目录问题，而是：
- 客户端长轮询超时时间过短：
nacos.discovery.watch-delay默认 30000ms，但在高并发注册场景下可能被压垮，建议调大至 60000 - Nacos Server 启用了鉴权但客户端未配
nacos.username/nacos.password，导致心跳请求 403，服务被误判下线 - 服务名含下划线（如
user_service）——Nacos 2.x 默认开启严格模式，会拒绝注册，需在 Server 端配置nacos.naming.validation.pattern=^[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9]$放宽限制
本地缓存位置实际固定为 ${user.home}/.nacos/naming/，强行修改系统属性 nacos.naming.cache.dir 不会改变行为，只会让日志输出误导性路径。
