Spring Boot容器初始化完成后执行注入回调的核心是选择与“所有Bean已实例化、依赖已注入、容器已就绪”阶段严格对齐的机制：①@PostConstruct用于单Bean轻量初始化；②CommandLineRunner/ApplicationRunner适用于应用级启动后业务逻辑；③ContextRefreshedEvent监听适合事件驱动与全局协调；④InitializingBean/init-method为遗留场景补充。
Spring Boot 容器初始化完成后执行注入回调，核心是利用 Spring 生命周期中“所有 Bean 已实例化、依赖已注入、容器已就绪”这一稳定时机。此时你既能安全使用任何已注册的 Bean，又不会干扰启动流程。关键不是“手动触发”，而是选择与该阶段严格对齐的回调机制。
@PostConstruct：Bean 级别的初始化回调
这是最轻量、最常用的方式，适用于单个 Bean 的初始化逻辑。
- 方法必须标注 @PostConstruct，返回类型为 void，无参数，不能是 private
- 执行时机明确：构造函数 → @Autowired 注入完成 → @PostConstruct 方法被调用
- 它属于 Java 规范（JSR-250），不耦合 Spring，适合通用初始化，比如加载配置缓存、校验必填属性、预热本地计算资源
- 注意：它在每个 Bean 实例上独立执行，不保证跨 Bean 的执行顺序
CommandLineRunner / ApplicationRunner：应用级启动后回调
当你需要在整个容器刷新完毕、Web 服务端口已开启之后执行业务初始化（如预加载数据库字典、发送启动通知、检查外部依赖连通性），这两个接口更合适。
- Spring Boot 在 refresh() 完成后统一扫描并按顺序执行所有 CommandLineRunner 或 ApplicationRunner 的 run() 方法
- 可通过 @Order 或实现 Ordered 接口控制多个 runner 的执行次序
- run() 方法内可自由注入任意 Spring Bean——此时所有单例 Bean 都已“躺平”，完全可用
- CommandLineRunner 接收原始命令行参数 String[]；ApplicationRunner 封装为 ApplicationArguments，语义更清晰
ContextRefreshedEvent 监听：事件驱动式回调
如果你希望逻辑解耦、支持条件触发或需响应多次刷新（如开发时热部署导致上下文重建），监听容器事件更灵活。
- 实现 ApplicationListener
，重写 onApplicationEvent() - 该事件在 ApplicationContext 刷新完成、所有 Bean 初始化就绪后发布
- 一个典型场景是：仅在主上下文（非子上下文）中执行一次初始化，可通过 event.getApplicationContext().getParent() == null 来判断
- 相比 @PostConstruct 和 Runner，它更适合做全局协调类操作，而非单 Bean 内部状态设置
InitializingBean 接口与 init-method：XML/JavaConfig 场景补充
虽不如前三种现代常用，但在某些遗留项目或需显式声明初始化方法时仍有价值。
- 实现 InitializingBean 接口，重写 afterPropertiesSet()，效果等同于 @PostConstruct
- 在 @Bean 方法中指定 initMethod = "init"，或 XML 中配置 init-method，原理一致
- 注意：afterPropertiesSet() 和 @PostConstruct 会按声明顺序先后执行，若同时存在，@PostConstruct 先于 afterPropertiesSet()
