1. 从一次线上故障说起：为什么默认配置注册值得单独拎出来讲
去年冬天，一个跑了快两年的订单服务突然开始间歇性报错，日志里全是feign.RetryableException: connect timed out。运维第一反应是网络抖动，查了链路监控发现下游服务响应正常，连接池也没打满。最后定位到的问题让人哭笑不得——团队里一位同学在某个业务模块的启动类上加了@EnableFeignClients(basePackages = "com.xxx.remote")，而这个包路径下恰好有一个历史遗留的Feign客户端，它的Request.Options连接超时被硬编码成了200毫秒。更关键的是，这个客户端在容器启动时被注册成了默认配置，导致其他所有没有显式指定配置的Feign客户端都继承了这个"短命"的超时设置。
这件事让我意识到，@EnableFeignClients这个注解远不是"加在启动类上就完事"那么简单。它背后牵扯到Spring Cloud OpenFeign的配置注册机制、默认配置的优先级规则、以及组件扫描的边界控制。很多人用了两三年Feign，对@EnableFeignClients的认知还停留在"不加这个注解Feign客户端不生效"的层面，至于它怎么注册默认配置、默认配置和自定义配置谁覆盖谁、defaultConfiguration属性到底在什么场景下用，基本靠猜。
这篇内容就围绕@EnableFeignClients的默认配置注册这条线展开。我会从注解的属性结构讲起，拆解defaultConfiguration的注册时机和生效范围，用实际代码演示默认配置如何被应用到每一个Feign客户端，再对比@FeignClient上的configuration属性与它的优先级关系。中间会穿插几个我踩过的坑，比如默认配置类被组件扫描重复注册、配置类里放了@Bean方法导致全局污染、以及basePackages写错导致默认配置"看起来没生效"的排查过程。
适合谁看？如果你已经在项目里用Feign做服务间调用，但每次加新客户端都要复制一遍配置类，或者遇到过"改了配置不生效""超时时间莫名其妙变短"这类问题，那这篇内容应该能帮你把这块知识补全。如果你刚接触Spring Cloud，也可以从默认配置这个切入点理解Feign的配置体系，比直接啃源码要轻松不少。
2. @EnableFeignClients的属性拆解：defaultConfiguration到底管什么
2.1 注解的五个核心属性及其职责边界
先看@EnableFeignClients注解的定义，它一共有五个属性，每个属性的职责边界其实很清晰，但实际用的时候经常被混着用。
@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented @Import(FeignClientsRegistrar.class) public @interface EnableFeignClients { String[] value() default {}; String[] basePackages() default {}; Class<?>[] basePackageClasses() default {}; Class<?>[] defaultConfiguration() default {}; Class<?>[] clients() default {}; }value和basePackages是等价的，都是指定Feign客户端接口的扫描包路径，basePackageClasses是指定一个或多个类，以这些类所在的包作为扫描基准。这三个属性解决的是"去哪里找@FeignClient接口"的问题。
clients属性用得比较少，它允许你直接指定具体的Feign客户端类，跳过包扫描。这个属性在写单元测试或者需要精确控制加载哪些客户端时有用，但日常业务开发基本不会碰。
重点说defaultConfiguration。它的类型是Class<?>[]，意思是你可以传入多个配置类，这些配置类会被注册为所有Feign客户端的默认配置。注意这里的措辞——"所有"，意味着只要是通过这个@EnableFeignClients注解扫描注册的Feign客户端，都会应用这些默认配置，除非某个客户端通过@FeignClient的configuration属性显式指定了自己的配置。
这里有一个容易混淆的点：defaultConfiguration指定的配置类，和@FeignClient的configuration属性指定的配置类，在注册机制上走的是两条不同的路径。前者是在FeignClientsRegistrar扫描过程中作为"默认配置"注册到容器里的，后者是在处理每个@FeignClient注解时作为"该客户端的专属配置"注册的。两条路径的注册时机和Bean名称生成规则都不一样，这直接影响了后面要讲的优先级问题。
2.2 默认配置的注册时机：FeignClientsRegistrar做了什么
@EnableFeignClients注解上有一个@Import(FeignClientsRegistrar.class)，这是整个注册流程的入口。FeignClientsRegistrar实现了ImportBeanDefinitionRegistrar接口，在Spring容器启动时，registerBeanDefinitions方法会被调用。
这个方法内部做了两件主要的事情，顺序很关键：
@Override public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) { registerDefaultConfiguration(metadata, registry); registerFeignClients(metadata, registry); }registerDefaultConfiguration先执行，它负责把defaultConfiguration属性里指定的配置类注册到容器中。registerFeignClients后执行，它扫描包路径下的@FeignClient接口，为每个接口创建FeignClientFactoryBean的Bean定义。
这个顺序意味着：默认配置类在Feign客户端Bean定义创建之前就已经注册好了。当后续每个Feign客户端Bean被实例化时，它会去容器里查找默认配置，然后和自己的专属配置合并。
registerDefaultConfiguration的内部逻辑大致是这样的：
private void registerDefaultConfiguration(AnnotationMetadata metadata, BeanDefinitionRegistry registry) { Map<String, Object> defaultAttrs = metadata .getAnnotationAttributes(EnableFeignClients.class.getName(), true); if (defaultAttrs != null && defaultAttrs.containsKey("defaultConfiguration")) { String name; if (metadata.hasEnclosingClass()) { name = "default." + metadata.getEnclosingClassName(); } else { name = "default." + metadata.getClassName(); } registerClientConfiguration(registry, name, defaultAttrs.get("defaultConfiguration")); } }注意name的生成规则：如果@EnableFeignClients标注在内部类上，用外部类名；否则用当前类名。最终注册的Bean名称是default.加上类名。这个命名规则很重要，因为后面排查"默认配置是否注册成功"时，就是通过这个Bean名称去容器里找的。
registerClientConfiguration方法会把配置类包装成一个FeignClientSpecification对象，注册到容器中。FeignClientSpecification是Feign配置的核心载体，它持有一个配置类数组和一个名称。每个Feign客户端在创建时，都会拿到一个FeignClientSpecification列表，列表里包含了默认配置和专属配置。
2.3 一个容易忽略的细节：默认配置类的Bean定义注册方式
registerClientConfiguration在注册配置类时，并不是直接把配置类本身注册成一个Bean，而是注册了一个FeignClientSpecification类型的Bean，Bean名称就是前面生成的default.xxx，构造参数里传入了配置类的Class对象数组。
private void registerClientConfiguration(BeanDefinitionRegistry registry, Object name, Object configuration) { BeanDefinitionBuilder builder = BeanDefinitionBuilder .genericBeanDefinition(FeignClientSpecification.class); builder.addConstructorArgValue(name); builder.addConstructorArgValue(configuration); registry.registerBeanDefinition( name + "." + FeignClientSpecification.class.getSimpleName(), builder.getBeanDefinition()); }这意味着默认配置类本身不会被注册成一个普通的Spring Bean。它只是作为FeignClientSpecification的一个属性存在。这一点非常关键，因为很多人会误以为默认配置类会被Spring容器管理，然后在配置类里注入其他Bean，结果发现注入失败。
我见过一个典型的错误用法：在默认配置类里写了一个@Bean方法，方法参数里注入了DataSource，想根据数据源动态设置超时时间。结果启动时报NoSuchBeanDefinitionException，因为配置类本身没有被注册为Bean，@Bean方法自然也不会被处理。
注意：
defaultConfiguration指定的配置类，其内部的@Bean方法只有在Feign客户端创建时才会被解析，而且解析时使用的不是Spring容器的完整上下文，而是一个独立的FeignContext。这个上下文里只包含Feign相关的配置Bean，不包含业务Bean。
3. 默认配置如何被应用到每一个Feign客户端
3.1 FeignClientFactoryBean的配置获取链路
每个@FeignClient接口最终都会被注册成一个FeignClientFactoryBean。当这个FactoryBean的getObject()方法被调用时，它会通过FeignContext来获取配置。
FeignContext继承自NamedContextFactory，它的核心逻辑是为每个Feign客户端创建一个独立的子容器（AnnotationConfigApplicationContext）。这个子容器里会注册两类配置：
- 默认配置：来自
@EnableFeignClients的defaultConfiguration属性 - 专属配置：来自
@FeignClient的configuration属性
NamedContextFactory在创建子容器时，会先查找容器中所有FeignClientSpecification类型的Bean，然后根据名称匹配。默认配置的FeignClientSpecification名称是default.xxx，而每个Feign客户端的专属配置名称是客户端名称.FeignClientSpecification。
在FeignClientFactoryBean.configureFeign方法中，配置的获取逻辑大致如下：
protected void configureFeign(FeignContext context, Feign.Builder builder) { FeignClientProperties properties = applicationContext.getBean(FeignClientProperties.class); if (properties != null) { // 从配置文件读取配置 } else { // 从FeignContext获取配置 configureUsingConfiguration(context, builder); } }configureUsingConfiguration方法会从FeignContext中获取FeignLoggerFactory、Encoder、Decoder、Contract、Retryer、Request.Options等组件。获取时传入的客户端名称就是@FeignClient的name或value属性值。
FeignContext在查找这些组件时，会先在专属配置的子容器里找，找不到再去默认配置的子容器里找。这个查找顺序决定了专属配置优先于默认配置。
3.2 默认配置与专属配置的优先级验证
光说理论不够直观，写段代码验证一下。假设有一个默认配置类和一个专属配置类，都定义了Request.Options这个Bean。
// 默认配置类 public class DefaultFeignConfig { @Bean public Request.Options defaultOptions() { return new Request.Options(5000, 10000); } } // 专属配置类 public class OrderFeignConfig { @Bean public Request.Options orderOptions() { return new Request.Options(2000, 3000); } }启动类上这样配置：
@EnableFeignClients( basePackages = "com.example.remote", defaultConfiguration = DefaultFeignConfig.class )订单服务的Feign客户端这样写：
@FeignClient( name = "order-service", configuration = OrderFeignConfig.class ) public interface OrderFeignClient { // ... }另一个没有指定configuration的客户端：
@FeignClient(name = "user-service") public interface UserFeignClient { // ... }实测结果是：OrderFeignClient使用的是OrderFeignConfig里的Request.Options(2000, 3000)，而UserFeignClient使用的是DefaultFeignConfig里的Request.Options(5000, 10000)。
这个结果符合预期，但有一个细节值得注意：OrderFeignConfig里的Bean名称是orderOptions，DefaultFeignConfig里的Bean名称是defaultOptions，两个名称不同。如果两个配置类里的Bean名称相同，比如都叫requestOptions，会不会冲突？
答案是不会冲突，因为它们在两个不同的子容器里。FeignContext为每个客户端创建独立的子容器，专属配置的Bean在order-service的子容器里，默认配置的Bean在default.xxx的子容器里。查找时先查专属子容器，找到就直接返回，不会再去默认子容器里找。所以Bean名称相同也不会报错，只是专属配置会"遮蔽"默认配置。
3.3 默认配置的生效范围：只影响通过该注解注册的客户端
这里有一个很容易踩的坑：defaultConfiguration的生效范围仅限于通过当前@EnableFeignClients注解扫描注册的Feign客户端。
什么意思？假设你的项目里有多个模块，每个模块有自己的启动类，各自标注了@EnableFeignClients。模块A的注解里配置了defaultConfiguration = DefaultFeignConfig.class，模块B的注解里没有配置defaultConfiguration。那么模块B扫描到的Feign客户端不会应用模块A的默认配置。
这个结论看起来理所当然，但实际项目中经常出问题。比如一个多模块项目，公共模块里定义了一个@EnableFeignClients的配置类，业务模块通过@Import引入。如果公共模块的注解里配了defaultConfiguration，业务模块引入后，业务模块自己扫描的Feign客户端会应用这个默认配置，但业务模块如果又加了自己的@EnableFeignClients，两个注解的默认配置会同时注册，最终哪个生效取决于Bean名称是否冲突。
我遇到过更隐蔽的情况：两个@EnableFeignClients注解的defaultConfiguration指向同一个配置类，但标注在不同的类上。由于Bean名称是default.加上类名，两个注解注册的FeignClientSpecification名称不同，所以容器里会有两个默认配置的Specification。Feign客户端在查找默认配置时，会拿到一个列表，具体用哪个取决于NamedContextFactory的查找逻辑——它会遍历所有Specification，把匹配的配置类都注册到子容器里。如果两个配置类里有同名的Bean，后注册的会覆盖先注册的，但顺序不确定，这就埋下了隐患。
实操建议：一个应用里尽量只保留一个
@EnableFeignClients注解。如果确实需要多个，确保它们的defaultConfiguration不要有重叠的Bean定义，或者干脆只在一个注解上配置默认配置。
4. 默认配置类里该放什么、不该放什么
4.1 适合放在默认配置里的组件
默认配置的核心价值是"一次定义，全局复用"。适合放在默认配置里的，是那些所有Feign客户端都需要的、且配置值一致的组件。根据我的经验，以下几类组件比较适合：
日志级别配置。Feign的日志级别有NONE、BASIC、HEADERS、FULL四个档位。开发环境通常用FULL方便排查问题，生产环境用BASIC避免日志量过大。把Logger.Level的Bean定义放在默认配置里，所有客户端统一生效，不用每个客户端单独配。
public class DefaultFeignConfig { @Bean public Logger.Level feignLoggerLevel() { return Logger.Level.BASIC; } }重试策略。Feign默认的重试策略是Retryer.NEVER_RETRY，即不重试。如果业务上需要统一的重试逻辑，比如对GET请求重试3次，可以在这里定义。
@Bean public Retryer feignRetryer() { return new Retryer.Default(100, 1000, 3); }请求超时时间。这个要谨慎，因为不同下游服务的响应时间差异可能很大。如果所有下游服务的性能基线比较接近，可以放在默认配置里统一设置。如果差异大，建议放在各自的专属配置里。
编解码器。如果项目里统一使用JSON编解码，且没有特殊格式需求，默认的SpringDecoder和SpringEncoder已经够用。但如果需要支持XML或者自定义格式，可以在默认配置里替换。
请求拦截器。比如统一添加认证头、链路追踪ID、租户ID等。这类拦截器通常所有客户端都需要，放在默认配置里最合适。
@Bean public RequestInterceptor authRequestInterceptor() { return template -> { template.header("X-Auth-Token", getToken()); template.header("X-Trace-Id", getTraceId()); }; }4.2 不建议放在默认配置里的组件
Request.Options超时配置。前面已经说过，不同下游服务的超时需求不同。一个查询服务可能200毫秒就返回，一个报表服务可能要30秒。把超时放在默认配置里，要么设得太短导致报表服务超时，要么设得太长导致查询服务故障时线程被长时间占用。我的做法是：默认配置里给一个"兜底"的超时值（比如连接5秒、读取10秒），然后在需要特殊超时的客户端上用专属配置覆盖。
ErrorDecoder。错误解码器通常需要根据下游服务的错误码格式来定制。不同下游服务的错误响应结构可能完全不同，放在默认配置里很难通用。建议每个客户端或者每组客户端单独配置。
Contract。Spring Cloud默认使用SpringMvcContract，支持Spring MVC注解。如果某个客户端需要支持JAX-RS注解，需要单独配置Contract。这种情况比较少见，但一旦出现，放在默认配置里会影响其他客户端。
任何依赖业务Bean的组件。前面提过，默认配置类本身不是Spring Bean，它的@Bean方法在FeignContext子容器里执行。子容器里只有Feign相关的Bean，没有业务Bean。如果在@Bean方法里注入DataSource、RedisTemplate这类业务Bean，启动时会直接报错。
4.3 一个真实的踩坑案例：默认配置类被重复注册
这个坑我在两个项目里都遇到过，值得单独说一下。
场景是这样的：默认配置类DefaultFeignConfig上不小心加了@Configuration注解。
@Configuration // 这个注解是多余的，而且会引发问题 public class DefaultFeignConfig { @Bean public Logger.Level feignLoggerLevel() { return Logger.Level.BASIC; } }如果这个类所在的包恰好被@SpringBootApplication的组件扫描覆盖到，那么Spring容器会把它注册成一个普通的配置类，里面的@Bean方法会被执行，Logger.Level会被注册到根容器里。
同时，@EnableFeignClients的defaultConfiguration又把它注册到了FeignContext的子容器里。结果是：根容器里有一个Logger.LevelBean，每个Feign客户端的子容器里也有一个Logger.LevelBean。
这会导致两个问题。第一，根容器里的Logger.LevelBean可能会和其他配置冲突，比如项目里还有另一个地方定义了Logger.Level，导致NoUniqueBeanDefinitionException。第二，Feign客户端在查找Logger.Level时，会先在子容器里找，找到的是默认配置里的那个，看起来没问题。但如果某个客户端通过@FeignClient的configuration指定了专属配置，专属配置里没有定义Logger.Level，那么它会去默认配置的子容器里找，而不是根容器。根容器里的那个Bean就成了"僵尸Bean"，白白占用资源。
正确的做法是：默认配置类不要加@Configuration注解。它只是一个普通的Java类，里面的@Bean方法由FeignContext在创建子容器时解析。如果加了@Configuration，一定要确保它不在组件扫描的路径下，或者用@ComponentScan的排除规则把它排除掉。
排查技巧：如果怀疑默认配置类被重复注册，可以在启动后打印容器里所有
Logger.Level类型的Bean名称。如果出现了两个，一个是default.xxx相关的，一个是根容器里的，那就说明被重复注册了。
5. 默认配置不生效的排查路径与常见原因
5.1 从Bean注册到配置应用的完整排查链路
默认配置不生效，表现通常是：明明在defaultConfiguration里配了超时时间或者拦截器，但实际调用时用的还是Feign的默认值。排查这个问题，我一般按照从外到内的顺序，分四步走。
第一步：确认@EnableFeignClients注解是否被处理。在启动类上打断点，或者加一行日志，确认FeignClientsRegistrar.registerBeanDefinitions方法被调用了。如果没被调用，说明注解没生效，可能是启动类没加注解，或者注解加在了不会被扫描到的类上。
第二步：确认默认配置的FeignClientSpecification是否注册成功。在容器启动后，通过ApplicationContext.getBeanNamesForType(FeignClientSpecification.class)获取所有Specification的Bean名称。如果名称列表里没有default.开头的，说明defaultConfiguration属性没配或者配错了。
第三步：确认Feign客户端是否匹配到了默认配置。FeignContext在查找配置时，会根据客户端名称去匹配Specification。默认配置的Specification名称是default.xxx，它不包含具体的客户端名称，所以理论上应该匹配所有客户端。但如果@FeignClient的name属性为空，或者contextId配置有问题，可能导致匹配失败。
第四步：确认配置类里的Bean是否被正确解析。在配置类的@Bean方法里打断点，看方法是否被调用。如果没被调用，说明配置类没有被加载到子容器里。常见原因是配置类里用了@ConditionalOnMissingBean之类的条件注解，条件不满足导致Bean没创建。
5.2 三个高频原因：包路径、注解冲突、配置类位置
根据我处理过的案例，默认配置不生效的原因集中在三个地方。
包路径写错。basePackages指定的路径必须能扫描到@FeignClient接口。如果路径写错，Feign客户端根本不会被注册，默认配置自然也无从谈起。这个问题的隐蔽之处在于：如果项目里有多个@EnableFeignClients注解，一个路径写对了，一个写错了，写错的那个不会报错，只是静默地不注册任何客户端。排查时容易误以为是默认配置的问题，实际上是客户端压根没注册。
注解冲突。前面提过，多个@EnableFeignClients注解的defaultConfiguration可能冲突。还有一种情况是：@EnableFeignClients和@EnableFeignClients的变体注解（比如某些框架封装的注解）同时存在，导致注册了多份默认配置。这种情况下，Feign客户端拿到的默认配置列表里有多份配置，Bean的覆盖顺序不确定。
配置类位置不当。如果默认配置类放在@SpringBootApplication扫描的包路径下，且加了@Configuration注解，会被根容器注册。虽然Feign客户端仍然能从子容器里拿到配置，但根容器里的Bean可能引发其他问题。更严重的是，如果配置类里定义了RequestInterceptor，根容器里的这个拦截器会被应用到所有HTTP客户端（包括RestTemplate），造成意料之外的副作用。
5.3 用日志验证默认配置是否生效
最直接的验证方式是在默认配置类里加日志。比如定义一个RequestInterceptor，在拦截方法里打印一行日志：
@Bean public RequestInterceptor logInterceptor() { return template -> { log.info("Feign request to: {}", template.url()); }; }如果每次Feign调用都能看到这行日志，说明默认配置生效了。如果看不到，说明配置没被应用。
另一个验证点是超时时间。在默认配置里设置一个很短的超时，比如连接1秒、读取1秒，然后调用一个响应较慢的下游服务。如果抛出Read timed out异常，说明超时配置生效了。如果调用正常返回，说明超时配置没生效，用的还是Feign的默认值（连接10秒、读取60秒）。
注意：用超时时间来验证时，要确保下游服务确实有慢响应的情况，否则可能因为响应太快而看不出差异。可以临时在下游服务里加一个
Thread.sleep来模拟慢响应。
6. 默认配置与配置文件方式的取舍
6.1 两种配置方式的本质区别
Spring Cloud OpenFeign支持两种配置方式：Java配置类方式和配置文件方式。默认配置同样可以用这两种方式来实现。
Java配置类方式就是前面讲的defaultConfiguration属性。配置文件方式是在application.yml里通过feign.client.config.default来配置：
feign: client: config: default: connectTimeout: 5000 readTimeout: 10000 loggerLevel: basic这两种方式的本质区别在于：Java配置类方式注册的是FeignClientSpecification，配置类里的@Bean方法会被FeignContext解析；配置文件方式注册的是FeignClientProperties，在FeignClientFactoryBean.configureFeign方法里被读取。
从优先级上看，配置文件方式的优先级高于Java配置类方式。在configureFeign方法里，会先检查FeignClientProperties是否存在，如果存在且配置了对应客户端的属性，就直接用配置文件里的值，不再走configureUsingConfiguration方法。
这个优先级规则意味着：如果你在defaultConfiguration里配了超时5秒，在application.yml里配了feign.client.config.default.connectTimeout=3000，最终生效的是3秒。
6.2 什么场景下用Java配置类，什么场景下用配置文件
我的经验是：需要定义Bean的场景用Java配置类，纯属性配置的场景用配置文件。
比如RequestInterceptor、ErrorDecoder、Retryer这些需要实例化的组件，只能用Java配置类。而超时时间、日志级别这些简单的属性，用配置文件更简洁，而且可以在不同环境（开发、测试、生产）用不同的application-{profile}.yml来覆盖，不需要改代码。
一个常见的组合用法是：用Java配置类定义RequestInterceptor和ErrorDecoder，用配置文件定义超时时间和日志级别。这样既保留了代码的灵活性，又利用了配置文件的環境隔离能力。
@EnableFeignClients( basePackages = "com.example.remote", defaultConfiguration = DefaultFeignConfig.class )feign: client: config: default: connectTimeout: 5000 readTimeout: 10000 loggerLevel: basic这种组合下，DefaultFeignConfig里的RequestInterceptor和ErrorDecoder会生效，超时和日志级别以配置文件为准。
6.3 配置文件方式的局限性
配置文件方式虽然简洁，但有几个局限性需要注意。
无法定义复杂Bean。配置文件只能配置简单的属性值，无法定义RequestInterceptor这种需要实现接口的Bean。虽然可以通过自定义配置属性类来扩展，但复杂度较高，不如直接用Java配置类。
配置项有限。FeignClientProperties.FeignClientConfiguration类里定义的配置项是有限的，主要包括loggerLevel、connectTimeout、readTimeout、retryer、errorDecoder、requestInterceptors等。如果需要的配置项不在这个列表里，配置文件方式就无能为力了。
类型转换的坑。配置文件里的值最终会被绑定到FeignClientConfiguration对象上。如果类型不匹配，比如把connectTimeout写成了字符串"5s"，启动时会报绑定异常。而Java配置类方式在编译期就能发现类型问题。
实操建议：如果团队里对Feign的配置方式没有统一规范，建议在项目文档里明确约定——哪些配置走Java类，哪些走配置文件。避免出现"同一个配置项在两个地方都配了，值还不一样"的情况。
7. 几个值得记住的实操经验
关于@EnableFeignClients的默认配置注册，最后再分享几个我在实际项目中总结的经验点。
默认配置的Bean名称不要和专属配置的Bean名称相同。虽然前面说过，专属配置会"遮蔽"默认配置，同名Bean不会报错，但这会让排查问题变得困难。因为你看日志或者调试时，很难一眼看出当前生效的是哪个配置。建议默认配置里的Bean名称加一个default前缀，专属配置里的Bean名称加客户端名称前缀，这样从Bean名称就能判断来源。
默认配置类不要放在会被组件扫描的包下。最安全的做法是放在一个独立的包，比如com.example.config.feign，然后在@SpringBootApplication的scanBasePackages里排除这个包。或者更简单——不加@Configuration注解，这样即使被扫描到，Spring也不会把它当成配置类处理。
多个@EnableFeignClients注解的defaultConfiguration要协调好。如果确实需要多个注解，建议只在一个注解上配置defaultConfiguration，其他注解不配。这样默认配置只有一份，不会出现覆盖顺序不确定的问题。
升级Spring Cloud版本时注意默认配置的兼容性。不同版本的Spring Cloud OpenFeign在默认配置的注册逻辑上有细微差异。比如在某些版本里，defaultConfiguration指定的配置类会被注册到根容器，而在另一些版本里只注册到FeignContext子容器。升级时如果发现默认配置的行为变了，先查版本变更日志，再看FeignClientsRegistrar的源码是否有调整。
用@FeignClient的contextId属性解决同名客户端的配置隔离问题。如果两个Feign客户端指向同一个服务名，但需要不同的配置，可以通过contextId来区分。contextId会作为FeignContext子容器的名称，不同contextId的客户端使用不同的子容器，配置互不影响。这个技巧在需要调用同一个服务的不同接口且配置不同的场景下很有用。
@FeignClient(name = "order-service", contextId = "orderQueryClient", configuration = QueryConfig.class) public interface OrderQueryClient { } @FeignClient(name = "order-service", contextId = "orderWriteClient", configuration = WriteConfig.class) public interface OrderWriteClient { }这两个客户端指向同一个服务，但使用不同的配置。如果没有contextId，它们会共享同一个子容器，配置会互相覆盖。
默认配置里的RequestInterceptor要注意执行顺序。如果默认配置和专属配置里都定义了RequestInterceptor，它们的执行顺序是不确定的。如果拦截器之间有依赖关系（比如一个拦截器要读取另一个拦截器设置的header），需要显式指定顺序。可以通过实现Ordered接口或者使用@Order注解来指定。
@Bean @Order(1) public RequestInterceptor authInterceptor() { return template -> template.header("X-Auth", getToken()); } @Bean @Order(2) public RequestInterceptor traceInterceptor() { return template -> template.header("X-Trace", getTraceId()); }这些经验点看起来琐碎，但每一个都是我在实际项目中踩过坑之后总结出来的。默认配置这个机制本身不复杂，复杂的是它在不同场景下的行为差异，以及和其他配置方式的交互。把这块搞清楚，Feign的配置体系基本就通了。
