静态代码块不能直接完成依赖注入，因其在类加载时执行、早于Spring容器初始化Bean，导致依赖对象未创建而引发空指针；应改用延迟注入+静态setter方式，由@Configuration Bean方法安全赋值。
静态代码块本身不能直接完成依赖注入，因为它在类加载时执行，早于 Spring 容器初始化 Bean。此时依赖对象尚未创建，强行在静态块中访问 Spring 管理的 Bean 会导致 NullPointerException 或空引用。
静态代码块的局限性
静态代码块（static { ... }）属于类加载阶段行为，由 JVM 触发，不经过 Spring 生命周期管理。它无法感知容器上下文，也不能自动获取 @Autowired 注入的实例。常见错误写法如下：
- 在静态块里直接调用
ApplicationContext.getBean()—— 除非手动持有上下文引用，否则会报空指针或上下文未初始化异常 - 试图在静态块中给
static字段赋值为 Spring Bean —— 此时 Bean 尚未创建，字段将保持 null - 把依赖注入逻辑全塞进静态块，绕过 IoC 容器 —— 导致测试困难、配置不可控、无法使用 AOP 或事务等 Spring 特性
可行替代方案：延迟注入 + 静态入口
若需在静态工具类中使用 Spring 管理的依赖，推荐采用“先定义静态字段 + 后注入”的方式，避开静态块限制：
- 移除所有
@Autowired注解在static字段上（Spring 不支持） - 声明
private static XxxService service;，不初始化 - 提供
public static void setXxxService(XxxService s)方法供外部注入 - 在 Spring 配置类中，通过
@Bean方法接收已创建的 Bean，并调用该 setter
Spring 配置类触发注入
利用 Spring 的 Bean 创建顺序保障依赖可用性：
立即学习“Java免费学习笔记（深入）”；
@Configuration
public class StaticInjectConfig {
@Bean
public void injectToUtils(UserService userService) {
MyUtils.setUserService(userService); // 调用静态 setter
}
}
Spring 会确保 UserService 实例已创建完毕，再执行该 @Bean 方法，从而安全完成静态字段赋值。
避免滥用静态注入的提醒
静态注入适合极少数场景，比如日志工具、全局配置访问器、跨模块共享服务等真正需要类级别单例且不依赖生命周期管理的组件。但要注意：
- 单元测试时难以 mock，需配合
reset方法清空状态 - 多线程环境下，若 setter 非线程安全，可能引发竞态问题
- 无法享受 Spring 的代理增强（如
@Transactional、@Cacheable）
