spring boot 中 commandlinerunner 和 applicationrunner 用于应用上下文加载完成后、web 容器启动前执行初始化逻辑；前者接收原始命令行参数，适合轻量任务；后者通过 applicationarguments 提供结构化参数解析，适合动态行为控制；均支持 @order 排序且需注意异常处理与耗时操作异步化。
Spring Boot 提供了 CommandLineRunner 和 ApplicationRunner 两个接口，用于在应用上下文加载完成后、服务正式对外提供请求前执行初始化逻辑，比如缓存预热、数据库校验、远程配置拉取等。两者功能相似，但参数设计不同，选择取决于你是否需要解析命令行参数。
CommandLineRunner：适合简单参数处理
它只有一个 run(String... args) 方法，接收原始的命令行参数数组（即启动时加在 java -jar xxx.jar 后面的参数），适合做轻量级启动任务。
- 实现类需标注
@Component，Spring 会自动注册为 Bean - 多个 Runner 可通过
@Order或实现Ordered接口控制执行顺序（数值越小越先执行） - 若发生异常，应用默认会启动失败（除非捕获并处理）
示例：
@Component
@Order(1)
public class CachePreloader implements CommandLineRunner {
@Autowired
private RedisTemplate redisTemplate;
@Override
public void run(String... args) throws Exception {
// 从数据库查热点商品，写入 Redis
List<product> hotProducts = productMapper.getHotProducts();
hotProducts.forEach(p -> redisTemplate.opsForValue().set("product:" + p.getId(), p));
System.out.println("✅ 热点商品缓存预热完成");
}
}</product>
ApplicationRunner：支持结构化参数解析
它的 run(ApplicationArguments args) 方法传入的是封装好的 ApplicationArguments 对象，能更方便地区分非选项参数（getNonOptionArgs()）和带前缀的选项参数（如 --env=prod，用 getOptionNames() 和 getOptionValues() 获取）。
- 适合需要根据启动参数动态决定预热行为的场景（例如仅在 prod 环境预热）
- 参数解析更健壮，避免手动拆分字符串带来的错误
- 同样支持
@Order控制顺序
示例：
@Component
@Order(2)
public class ConfigSyncRunner implements ApplicationRunner {
@Value("${spring.profiles.active:dev}")
private String profile;
@Override
public void run(ApplicationArguments args) throws Exception {
if ("prod".equals(profile) && args.containsOption("preload")) {
syncRemoteConfig();
System.out.println("✅ 远程配置同步完成");
}
}
private void syncRemoteConfig() {
// 调用配置中心 API 拉取最新配置并加载到本地
}
}
执行时机与注意事项
这两个接口的 run() 方法会在 ApplicationContext 初始化完毕后、Web 容器（如 Tomcat）完全启动前执行。此时所有 Bean 已就绪，可安全注入和调用，但 HTTP 服务尚未监听端口，无法接收外部请求。
- 不要在
run()中执行耗时过长的操作（如全量数据导入），否则会拖慢启动速度，甚至触发健康检查超时 - 建议将重逻辑异步化（如用
TaskExecutor或@Async），同时记录日志或设置启动标志便于监控 - 若预热失败需降级，应明确处理异常，避免阻断整个应用启动（视业务容忍度决定是否吞掉异常）
替代方案：ApplicationRunner vs @PostConstruct vs ApplicationReadyEvent
@PostConstruct 在 Bean 初始化后立即执行，不保证其他 Bean 已创建完毕，不适合依赖复杂上下文的预热；ApplicationReadyEvent 是事件机制，在 Web 服务已启动、端口已监听后发布，适用于需要“服务就绪后”才触发的逻辑（如注册到 Nacos、发送启动通知），但不适合缓存预热这类需在服务可用前完成的任务。
- 优先选
CommandLineRunner或ApplicationRunner做启动预热 - 若需精确控制阶段，比如“端口监听后但流量接入前”，可结合
LivenessStateCallback或自定义 Health Indicator
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
