那天下午同事在群里问我：job.fetch.limit 改到 200 了怎么调度还在按 50 跑？

我第一反应是配置中心没推过来。老实说，去 Consul 上看了一眼，值确实是 200。

接下来我开始了一轮又一轮的排查。中间做了无数个“合理”的假设，被源码一个个打脸。

这条链上一共 7 个地方能让配置改了不生效，没有一个会抛异常。

至于第一回合，我猜是 @RefreshScope 的问题

先说清现象。同一个服务里两个配置类，读同一个配置项。两个都没标 @RefreshScope

@Component
@ConfigurationProperties
public class FetchProps {
private int limit = 50;// getter/setter 略
}
@Component
public class JobConfig {
@Value
private int limit;}

配置中心改值，上面那个立刻生效。下面那个纹丝不动.

I 当时就纳闷了：两个都没标注解，凭啥一个行一个不行？网上一查，都说 @Value 要配 @RefreshScope. 行。我给 JobConfig 补上注解，重启，再试。还是不行，

这就开始不对劲了。

使用者痛点一：你以为加个注解就能热更新，却发现根本无效！

说到第二回合，翻源码。发现我连代理类型都搞错了

I 为了证伪“框架有 bug”这个假设，我翻了一遍它的源码。一直以为 @RefreshScope 的代理规则是：类有接口就 JDK 动态代理，没接口才退回 CGLIB。结果一看注解自己的定义：

// RefreshScope:
@Scope
public @interface RefreshScope {
@AliasFor
ScopedProxyMode proxyMode default ScopedProxyMode.TARGET_CLASS;}

TARGET_CLASS 是写死在默认值里的！不过，

主要三件事让我彻底清醒：

• 每次通过代理调方法。都重新解析一次目标实例并加读锁。
• 刷新时清缓存、逐个 bean 拿写锁再销毁。
• 重建是懒的，在刷新之后第一个调用者线程上完成双检锁构造。

使用者痛点二：你以为只要 “刷新”。所有 bean 就瞬间更新，却忽略了代理与懒加载导致的延迟与资源泄漏风险！

再看第三回合，顺手纠正一个误解，它不是免费的

I 原以为只要标上就完事。但真正成本藏在暗处：

• 热方法多一次读锁 + target 解析；高频调用成本可观，
• 刷新期间写锁会堵住所有调用；如果 bean 多、配置多，一次刷新几乎停顿整个服务。
• @PreDestroy 会被调用。 连接池、HttpClient、Kafka Consumer 等资源，每次刷新都会销毁重建；若销毁逻辑粗糙，就成致命缺陷。
• @Configuration@RefreshScope 在 Bean 方法层级失效——仅标注 Configuration 类无法触发 Bean 的重建；正确位置应放在具体 @Bean 方法上。  
. . kotlin @Configuration @RefreshScope // ❌ 标错位置 public class ClientConfig { @Bean public HttpClient httpClient int timeout) { ... } } .

说到后果，

.;
• .
• .
• .
. …，

*此列表仅供示例，不代表实际链接*.
.