配置热更新不等于重启

传统做法改一个配置项就要重启应用才能生效，配置服务器打开了另一条路：给远程仓库推送新配置后，向运行中的应用实例发一个刷新信号（比如调用 /actuator/refresh 端点），触发一个内部事件，凡是监听这个事件的配置对象就会重新读取最新数据，应用本身完全不用重启、不用重新构建，变更还能在 Git 提交历史里留痕。这本质上是[[15-Factor方法论的定位]]里”管理任务作为一次性进程”这条原则的一种落地——把”刷新配置”做成一个可以被外部调用触发的独立操作，嵌进应用自身对外暴露的一个端点里。发散：热更新能力越强，越考验应用本身对配置变化的容忍度——如果某个配置项被缓存进了其他对象的构造阶段（不是运行时动态读取），刷新事件传到了也没用，这是热更新机制在实践中最容易踩的坑：不是所有配置都能真正”热”起来。