静态类不支持依赖注入，因其无实例生命周期且无法构造注入；替代方案包括：一、静态setter配合配置类驱动注入；二、applicationcontext持有器模式实现依赖查找；三、工厂方法封装委托给容器管理。
静态类本身不能参与依赖注入，因为它没有实例生命周期，容器无法在构造时为其注入依赖。这不是 Spring 或 .NET 等框架的缺陷，而是设计上的必然限制——静态成员属于类级别，与 IoC 容器管理的“实例级”依赖模型天然冲突。
为什么静态类不支持构造注入
构造注入要求对象通过构造函数接收依赖，而静态类不能被实例化，也就没有构造函数可调用。即使强行定义 static 构造函数（如 C# 中的 static ClassName()），它也只执行一次、不接受参数、无法访问容器上下文，更无法按需传入不同配置的 Bean 实例。
- 静态类加载发生在 JVM/.NET 类初始化阶段，早于容器启动完成
- 构造注入依赖容器对 Bean 实例的完整生命周期控制，静态类绕过了这一整套机制
- 若允许“静态构造注入”，将破坏多实例隔离、Profile 切换、AOP 增强等核心能力
替代方案一：静态 setter + 配置类驱动注入
适用于工具类、全局访问器等需要在静态方法中使用 Spring Bean 的场景。关键在于把“注入动作”从类加载阶段推迟到容器就绪之后。
- 声明
private static XxxService service;，不加@Autowired - 提供公开的
public static void setXxxService(XxxService s)方法 - 在
@Configuration类中定义无返回值@Bean方法，显式调用该 setter
Spring 会确保被依赖的 Bean 已创建完毕，再执行该方法，从而安全完成赋值。
替代方案二：ApplicationContext 持有器模式
通过实现 ApplicationContextAware 接口，将容器上下文保存为静态变量，后续静态方法可通过它主动获取 Bean。
- 编写一个
SpringContextHolder类，实现接口并保存ApplicationContext - 静态工具类中调用
context.getBean(XxxService.class)获取实例 - 注意：此方式属于依赖查找（DL），不是依赖注入（DI），需自行管理线程安全与生命周期感知
替代方案三：工厂方法封装静态访问
不暴露静态字段，而是用静态方法封装“按需获取”，内部委托给 Spring 管理的工厂 Bean。
- 定义普通
@Service工厂类，含getXxxService()方法 - 静态工具类中保留一个静态引用指向该工厂（通过 setter 注入或上下文获取）
- 所有静态调用转为
factory.getXxxService().doSomething()
这样既保持了静态入口的便利性，又把依赖交还给容器管理，避免硬编码和测试障碍。
