不能直接通过接口静态方法预热RPC服务存根，因为接口仅为契约定义，不包含运行时逻辑；预热必须在Spring容器启动后操作已注入的代理实例，推荐使用ApplicationRunner扫描并调用代理Bean。
不能直接通过接口的静态方法强制预热所有远程 RPC 服务存根。
原因：RPC 存根不是由接口静态方法驱动的
RPC 接口本身是纯契约（如 HelloWordService），它不包含网络连接、序列化、代理生成等运行时逻辑。其静态方法（如默认方法或 static 方法）仅用于编译期契约定义或工具辅助，不会触发客户端初始化、注册中心拉取、连接建立或远程调用。真正承载预热行为的是框架级组件（如 RPC 客户端 Starter、代理工厂、服务发现模块），而非接口定义本身。
正确预热的关键入口点
预热必须发生在 Spring 容器启动后、流量进入前，且需操作已装配的 RPC 基础设施：
-
获取已注入的 RPC 代理实例：通过
@RpcAutowired注入的服务引用（如HelloWordService）才是真实代理对象，调用其方法才会触发底层连接与首次调用流程 -
依赖框架自动装配的客户端组件：如
rpc-client-spring-boot-starter在启动时已注册RpcReferenceBean或ReferenceConfig实例，预热应基于这些 Bean 展开 -
避免在接口中硬编码预热逻辑：接口不应感知实现细节；把
static warmup()写进接口会破坏契约纯粹性，且无法保证该方法被调用
推荐落地方式：ApplicationRunner + 代理扫描
在 Spring Boot 应用中，使用 ApplicationRunner 扫描容器内所有 RPC 代理 Bean 并发起轻量调用：
- 通过
ApplicationContext.getBeansOfType(HelloWordService.class)获取全部已代理的服务实例 - 对每个实例执行一次空参或最小参数的试探调用（如
sayHello("warmup")），触发连接池建立、序列化初始化、负载均衡选节点等过程 - 异步执行并设超时（如 5 秒），失败仅记录 warn 日志，不阻塞主线程启动
- 配合分布式锁（如 RedisLock）防止多实例重复预热
补充说明：延迟暴露与预热协同
服务提供方也应启用 延迟暴露（如 Dubbo 的 delay="-1" 或自定义 starter 中的 rpc.server.delay 配置），让 provider 启动后先完成自身缓存/DB 连接初始化，再向注册中心注册地址。这样 consumer 预热时拉取到的地址才真正可用，避免“预热成功但调用失败”的假象。
