企业官网建设流程全解析

1. 这个让无数Java开发者卡壳的问题，到底卡在哪

只要用Spring做过几年开发，迟早会碰到这个需求：想在工具类或者静态方法里，直接用@Value或者@Autowired把某个配置项或者某个Bean塞进一个static字段里。结果写完之后一跑，字段还是null，怎么注入都进不去。网上搜一圈，答案五花八门，有的让加@Component，有的让写setter，有的直接说"静态的不能注入"。我早年第一次踩这个坑的时候，以为是注解位置写错了，折腾了一下午才搞明白根本不是注解的问题，是Spring对象管理机制和Java静态属性本质之间的冲突。

这个坑之所以经典，是因为它几乎是每个Spring项目都会遇到的问题。只要你是做Java后端开发的，写过工具类、静态配置读取、静态缓存初始化这类代码，就绕不开它。哪怕你用Spring Boot写了三年CRUD，也迟早有一天会被一个静态属性的null卡住。

先说结论：Spring的依赖注入是基于对象实例的，而静态属性属于类，不是属于实例。这个最基本的错位，导致了你不管用@Autowired还是@Value直接标注静态字段，Spring都无能为力。但是问题既然存在，解决方案自然也有。我这篇就把原理讲透，把常见的几种解法都摆出来，每个方案我会直接给出可复制的代码、适用场景和坑点，最后附上我实际项目里的完整案例。

2. 先搞清楚Spring的Bean生命周期，再说为什么注入不进静态属性

2.1 Spring默认注入机制的对象视角

要理解这个问题，得先弄明白Spring是怎么把依赖"送"到你的代码里的。Spring容器启动后会创建Bean实例，然后扫描@Autowired、@Resource、@Value这些注解，在对象实例上进行字段赋值或者调用setter方法。整个流程是：实例化对象 → 属性填充 → 初始化方法。

你看这个流程的关键词——"实例化"、"对象"、"属性填充"，全部都是针对实例层面。Spring容器维护的是一个个Bean实例，这些实例被存在容器里，当你需要一个Bean时，Spring把实例给你。而static字段是类级别的变量，它不归属于任何一个实例，类加载时就分配了内存，直接存在于方法区中（按主流JVM的划分方式来讲的话）。

Spring的注入框架设计的初衷是管理对象图和它们之间的依赖关系，它通过对象引用来组装系统。理论上它可以通过反射修改静态字段的值——反射确实能做到，所以问题的关键不是"技术上能不能改"，而是"Spring默认的设计根本就没打算去处理静态字段"。它只处理实例字段，这是它的工作边界。

2.2 为什么用了@Autowired标注static字段就是不行

有人会想：那我直接在字段上写@Autowired，Spring扫描的时候不该发现吗？这里有个容易被忽略的点：Spring的依赖注入处理器（比如AutowiredAnnotationBeanPostProcessor）确实会扫描字段上的注解，但它默认处理的字段是实例字段。当它判断目标字段带有static修饰符时，会直接跳过，不做任何处理，也不会报错。结果就是：你的静态字段依然是初始默认值（比如引用类型是null），程序照常启动，一切看起来正常，但一调用就空指针。

对于@Value注入静态字段也是如此。Spring在解析占位符（比如${config.xxx}）时，只会把解析结果赋给实例字段。如果目标字段是静态的，它不会去赋值，日志里也不会出现任何异常提示，这个"静默失败"的特性让排查难度直接拉满。

2.3 日常开发中最常踩到静态注入的场景

这个需求几乎都出现在工具类或者静态方法里。我总结了一下，主要就三种情况：

• 配置参数工具类：一个ConfigUtil，想用静态方法getUploadPath()从配置文件里读一个上传路径，用@Value("${file.upload-path}")标注静态字段。
• 静态缓存/上下文类：一个ContextHolder，内部有静态Map或者静态字段，希望在应用启动时从某个Bean里把数据填充进去。
• 工具类中调用业务服务：一个DateUtil里需要调用某个第三方接口的客户端Bean（比如某个SDK的Client），但工具方法全是静态的，没法通过构造器传对象。

这三种情况我都实际遇到过。很多人最初的直觉就是：直接在静态字段上加注解，简单粗暴。结果就是null。然后开始怀疑注解语法、怀疑配置、怀疑Spring Boot版本，最后才发现是静态字段的锅。

3. 方案一：setter方法注入，最经典的解法

3.1 为什么setter方法能绕开这个限制

既然静态字段不能直接注入，那就换个思路：用非静态的setter方法作为"桥梁"，让Spring把值通过实例方法传进来，方法内部再把值赋给静态字段。这相当于给静态字段开了一个"后门"。

因为setter方法本身是实例方法，Spring完全可以通过反射调用它。Spring扫描到@Autowired或@Value标注的方法时，会执行方法调用，把依赖传进去，方法内部把参数赋给静态字段。这样就绕开了"静态字段不被处理"的限制。

3.2 配置类注入（@Value场景）

先看最简单、最常用的写法，比如要给静态字段注入配置项：

@Component public class FileConfig { private static String uploadPath; private static int maxFileSize; @Value("${file.upload-path}") public void setUploadPath(String path) { FileConfig.uploadPath = path; } @Value("${file.max-size}") public void setMaxFileSize(int size) { FileConfig.maxFileSize = size; } public static String getUploadPath() { return uploadPath; } public static int getMaxFileSize() { return maxFileSize; } }

注意几点：类上必须加@Component或者被Spring扫描到，否则整个类都不会被容器管理，setter方法永远不会被调用。方法名可以随意，关键是方法有@Value注解，Spring会把配置值解析后调用这个方法。

这里我强烈建议在方法上加@Value而不是在字段上加。虽然Spring也支持在方法参数上写@Value("${...}")的方式，但那种写法在方法参数很多时容易混乱，直接标注方法最直观。

3.3 Bean依赖注入场景（@Autowired）

如果静态字段需要的是一个Bean，比如一个RedisTemplate或者某个服务类，写法类似：

@Component public class CacheSupport { private static RedisTemplate<String, Object> redisTemplate; @Autowired public void setRedisTemplate(RedisTemplate<String, Object> template) { CacheSupport.redisTemplate = template; } public static void put(String key, Object value) { redisTemplate.opsForValue().set(key, value); } public static Object get(String key) { return redisTemplate.opsForValue().get(key); } }

这里有个细节：@Autowired标注的方法如果只有一个参数，Spring会自动按类型查找Bean并调用方法。这个方法可以是public、private，甚至是包级可见的，Spring都能调用。但我推荐用public，一方面是语义清晰，另一方面是某些代理机制对非public方法有潜在干扰，虽然Spring自身反射调用没问题，但没必要给自己埋雷。

3.4 这个方案的优缺点和适用边界

这个方案是目前社区最主流、最推荐的方案。优点很明显：

• 代码直观，理解成本低，一个setter方法就能解决。
• 不引入额外的复杂机制，Spring原生支持。
• 生命周期可信赖：setter方法在Spring完成Bean属性填充时调用，时序可控。

缺点也有一些：

• 静态字段变成"可变"的了，如果在后续代码里不小心有人给静态字段直接赋值，可能造成意想不到的问题。
• 得额外写setter方法，代码量会多一点。
• 更重要的一个隐患：如果有多个Spring上下文（比如测试上下文、WebApplicationContext和RootApplicationContext并存），这个类的静态字段可能被不同容器反复赋值。虽然你在单上下文应用里几乎不会遇到，但在某些老项目里要警惕。

3.5 一个特别提示：千万别在构造器里给静态字段赋值

有人可能会说，既然setter能行，那我直接在构造器里写this.uploadPath = val不也一样？还真不一样。Spring在实例化类时使用的是无参构造器，如果你把@Value放在构造器参数上，构造器注入会用另一种方式绕过静态字段限制，这个后面讲。但如果你只是写了一个普通的有参构造器，Spring实例化时根本不会调用它，赋值逻辑不会执行，静态字段还是null。

还有人会在@PostConstruct方法里给静态字段赋值。这个方案的前提是：这个类有实例字段能拿到值，再在初始化方法里转赋给静态字段。这其实和setter方案是一个思路，只是时机从setter阶段挪到了初始化阶段。如果你已经有@PostConstruct在做别的初始化逻辑，顺带把静态字段赋值进去也是可以的。

4. 方案二：使用静态代码块读取Spring上下文，直接暴力获取

4.1 ApplicationContextAware方案

除了setter注入，还有一类思路是绕过Spring注入机制，直接获取Spring容器，然后从容器里拿Bean或者配置。这种方案的核心是让某个工具类实现ApplicationContextAware接口，把Spring容器存到静态字段里，之后在静态代码块或者静态方法中直接从容器获取。

@Component public class SpringContextUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; @Override public void setApplicationContext(ApplicationContext context) throws BeansException { SpringContextUtil.applicationContext = context; } public static <T> T getBean(Class<T> clazz) { return applicationContext.getBean(clazz); } public static Object getBean(String name) { return applicationContext.getBean(name); } public static String getProperty(String key) { return applicationContext.getEnvironment().getProperty(key); } }

写好之后，在任何一个静态方法里都能这样拿值：

public class CommonUtils { private static final String uploadPath; static { uploadPath = SpringContextUtil.getProperty("file.upload-path"); } public static String getUploadPath() { return uploadPath; } }

静态代码块在类加载的时候执行，SpringContextUtil里的容器肯定已经初始化了吗？不一定。这个方案有一个致命时序问题：如果CommonUtils在Spring容器还没完成初始化时就被某个类触发了类加载，静态代码块执行时SpringContextUtil.applicationContext还是null，直接空指针。而且更麻烦的是，类一旦加载完成，静态代码块不会再次执行，整个字段就永远都是初始值或者报错状态。

4.2 懒加载的单例持有者方案

为了解决时序问题，可以用懒加载的方式，把从容器取值的动作推迟到静态方法第一次被调用时：

@Component public class SpringContextUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; @Override public void setApplicationContext(ApplicationContext context) { SpringContextUtil.applicationContext = context; } public static ApplicationContext getApplicationContext() { return applicationContext; } } public class UploadPathHolder { public static String getUploadPath() { return SpringContextUtil.getApplicationContext() .getEnvironment() .getProperty("file.upload-path"); } }

每次调用都动态从容器里获取，虽然多了一次容器查找的开销，但对于读配置这种操作，微乎其微，换来的是绝对可靠的时序。这个方案的典型使用场景是：工具类本身不想被Spring管理（不想加@Component），又确实需要读取Spring环境配置或获取某个Bean。它让你在任何普通类、任何静态方法里都能拿到Spring容器里的东西，灵活性极高。

不过这个方案的缺点是侵入性比较强：项目中多了一个静态持有ApplicationContext的类，等于全局暴露了容器。团队协作时，别人可能随手就在代码里到处用SpringContextUtil.getBean("xxx")，导致依赖关系变得隐蔽，代码的可测试性下降。我的建议是：这只作为兜底手段，在极少数setter方案无法处理的场景下才用。

5. 方案三：构造器注入 + 静态持有，适合新代码的优雅做法

5.1 用实例"包装"静态依赖

如果你写的是新代码，从设计角度考虑，最干净的做法是：不要试图让静态属性直接依赖Spring，而是在建一个非静态的组件作为接口，内部通过静态字段暴露访问点。这个方案比直接setter更优雅的地方在于：静态字段使用final修饰，不可变性更好，也不存在被后续代码篡改的风险。

@Component public class DateService { private static DateService instance; private final DateTimeFormatter formatter; private final ZoneId zoneId; public DateService(DateTimeFormatter formatter, ZoneId zoneId) { this.formatter = formatter; this.zoneId = zoneId; DateService.instance = this; } public static DateService getInstance() { return instance; } public String format(LocalDateTime dateTime) { return formatter.format(dateTime); } public ZoneId getZoneId() { return zoneId; } }

这个方案利用构造器注入的时机（Spring在构造Bean实例时可以传入依赖），在构造器内部把当前实例赋给静态字段。因为Spring的构造器注入在非常早期就完成了，后续其他依赖这个静态字段的代码调用DateService.getInstance()时，实例引用已经就绪。

这个模式和setter方案本质上是类似的，但它在"静态字段持有实例"而不是"静态字段直接持有值"这个粒度上做了区分，语义更清晰：外部工具类通过DateService.getInstance().format(date)来使用服务，而不是直接操作一大把静态字段。

5.2 什么时候优先推荐构造器持有

我自己的经验是：当这个工具类内部有多个依赖（超过2个Bean或配置项）时，优先考虑这种"静态单例持有实例"的模式。因为setter方案里静态字段会越来越多，工具类的公共静态方法却只是简单转发，代码会显得凌乱。而持有实例后，调用方跟工具类的静态方法解耦，后续功能扩展时，你只需要改DateService内部方法即可，调用方无感。

举个例子，一个工具类需要 Redis、KafkaTemplate、ObjectMapper 三个Bean，用setter方案你要写：

private static RedisTemplate redisTemplate; private static KafkaTemplate kafkaTemplate; private static ObjectMapper objectMapper; @Autowired public void setRedisTemplate(RedisTemplate template) { ... } @Autowired public void setKafkaTemplate(KafkaTemplate template) { ... } @Autowired public void setObjectMapper(ObjectMapper mapper) { ... }

代码冗长，而且外部调用时依然通过静态方法。如果用实例持有方案，外部直接MessageTool.getInstance().sendMsg(...)，内部依赖全部作为实例字段，由构造器一次性传入，写起来干净很多。

5.3 要注意实例可能为null

这个方案有一个需要说明的地方：Spring容器加载是有顺序的，如果你的某个静态方法在Spring完成这个工具Bean的构造之前就被调用了，instance可能还是null。通常只要不是启动早期阶段，这个问题不会出现，因为类加载并调用静态方法通常发生在请求进来之后，Spring早就初始化完成了。

但如果你是初始化监听器、定时任务这种启动阶段代码，就得谨慎。此时稳妥的做法是配合@PostConstruct或者SmartInitializingSingleton做启动检查，确保静态实例已就绪。

6. 方案四：通过Environment获取配置，最被低估的做法

6.1 不注入字段，直接每次读环境

前面讲的方案都在"把值注入到静态字段"这条路上绕来绕去。但我们换个思路：静态方法里其实不一定需要"预先持有值"，完全可以每次调用时从Spring的Environment直接读取配置。环境对象本身是确定的、只需要一次拿到的依赖。

实现方式和ApplicationContextAware大同小异，但更轻量：

@Component public class ConfigEnv { private static Environment environment; @Autowired public void setEnvironment(Environment env) { ConfigEnv.environment = env; } public static String get(String key) { return environment.getProperty(key); } public static String get(String key, String defaultValue) { return environment.getProperty(key, defaultValue); } }

使用端：

public class UploadUtil { public static String getUploadPath() { return ConfigEnv.get("file.upload-path", "/tmp"); } public static int getMaxFileSize() { return ConfigEnv.get("file.max-size", Integer.class, 1048576); } }

这个做法的好处是：静态工具类不需要持有任何可变静态字段，每次调用从Environment读最新值。这在配置中心动态刷新场景下非常有用——比如配置在运行时被修改了，你不需要重新启动就能读到新值。而前面setter方案注入的值是一次性的，配置刷新后静态字段里的旧值不会自己更新。

6.2 跟@ConfigurationProperties配合的升级版

如果配置项很多，比如有几十个配置项，工具类一个个去读会写到手酸。更优雅的姿势是：用@ConfigurationProperties建一个配置对象，然后把这个对象注入给工具类的静态字段：

@Component @ConfigurationProperties(prefix = "file") public class FileProperties { private String uploadPath; private int maxFileSize; public String getUploadPath() { return uploadPath; } public void setUploadPath(String uploadPath) { this.uploadPath = uploadPath; } public int getMaxFileSize() { return maxFileSize; } public void setMaxFileSize(int maxFileSize) { this.maxFileSize = maxFileSize; } }

然后和setter方案结合：

@Component public class FileConfigBridge { private static FileProperties fileProperties; @Autowired public void setFileProperties(FileProperties props) { FileConfigBridge.fileProperties = props; } public static FileProperties getProperties() { return fileProperties; } }

之后工具类里通过FileConfigBridge.getProperties().getUploadPath()取值。这样配置结构清晰，还能自动获得IDE的代码补全，配置项不会拼错字符串。我强烈推荐在配置项超过5个的场景用这种方式，比散落的@Value字符串好维护太多。

7. 五种方案的横评和选型建议

我把能用的方案整理成一张表，方便你对照选型：

说实话，我自己项目中90%的场景用setter方法注入就够了，剩下的10%基本是配置项比较多或者有动态刷新需求，会搭配@ConfigurationProperties加Environment方案。至于ApplicationContextAware这种"万能工具类"，我一般是当作项目里的基础设施，放置一个SpringContextUtil备用，但不鼓励业务代码里到处直接getBean。

8. 实际项目中的完整案例：从零写一个静态配置工具类

8.1 需求场景

假设项目里需要一个SmsUtil短信工具类，所有业务代码通过静态方法发送短信。它需要以下依赖：

• 短信平台配置：appId、appSecret、signName（来自配置文件）
• RedisTemplate：用于短信频率限制、验证码存储
• 一个SmsClientBean：真正调用短信网关的客户端

8.2 两种实现的完整代码

我先用setter方案写一版：

@Component public class SmsUtil { private static String appId; private static String appSecret; private static String signName; private static RedisTemplate<String, Object> redisTemplate; private static SmsClient smsClient; @Value("${sms.app-id}") public void setAppId(String appId) { SmsUtil.appId = appId; } @Value("${sms.app-secret}") public void setAppSecret(String appSecret) { SmsUtil.appSecret = appSecret; } @Value("${sms.sign-name}") public void setSignName(String signName) { SmsUtil.signName = signName; } @Autowired public void setRedisTemplate(RedisTemplate<String, Object> template) { SmsUtil.redisTemplate = template; } @Autowired public void setSmsClient(SmsClient client) { SmsUtil.smsClient = client; } public static boolean sendVerifyCode(String phone, String code) { String key = "sms:code:" + phone; // 同一号码一分钟内只允许发送一次 Boolean exists = redisTemplate.hasKey(key); if (Boolean.TRUE.equals(exists)) { return false; } redisTemplate.opsForValue().set(key, code, 5, TimeUnit.MINUTES); return smsClient.send(phone, signName, String.format("您的验证码是%s，5分钟内有效", code)); } public static boolean verifyCode(String phone, String code) { String key = "sms:code:" + phone; Object saved = redisTemplate.opsForValue().get(key); if (saved != null && saved.toString().equals(code)) { redisTemplate.delete(key); return true; } return false; } }

这套代码在真实项目中可以直接用。业务代码里就是SmsUtil.sendVerifyCode("138xxxx", "123456")这么简单，完全不需要从Spring容器里取什么东西。

再说一遍使用条件：SmsUtil必须被Spring扫描到。如果你把它放在扫描路径之外，或者类上没加@Component，那么setter方法一次都不会被调用，静态字段全部是null，运行时会空指针。这是这个方案最容易被忽略的前提。

再看另一个升级思路：如果配置项很多，我会把配置部分抽象成SmsProperties：

@Component @ConfigurationProperties(prefix = "sms") public class SmsProperties { private String appId; private String appSecret; private String signName; // getter / setter 省略 }

然后SmsUtil里只需要两个setter：

@Component public class SmsUtil { private static SmsProperties smsProperties; private static SmsClient smsClient; @Autowired public void setSmsProperties(SmsProperties props) { SmsUtil.smsProperties = props; } @Autowired public void setSmsClient(SmsClient client) { SmsUtil.smsClient = client; } public static boolean sendVerifyCode(String phone, String code) { String template = String.format("您的验证码是%s，5分钟内有效", code); return smsClient.send(phone, smsProperties.getSignName(), template); } }

配置刷新、属性校验都塞到SmsProperties里，SmsUtil只关心业务逻辑，职责划分更清楚。

8.3 多实例场景或者单元测试环境下的坑

这个案例里还有一个容易踩的坑：单元测试时，Spring上下文没有完全加载，静态字段不会通过setter被赋值。你如果想纯写一个POJO单测去测SmsUtil.sendVerifyCode，会发现redisTemplate是null。

解决方式一种是mockito去mock静态方法，但静态方法mock比较麻烦。更推荐的是给SmsUtil增加一个包级可见的重新初始化方法，用来在测试里注入mock对象：

@VisibleForTesting static void reinitForTest(SmsProperties props, SmsClient client) { SmsUtil.smsProperties = props; SmsUtil.smsClient = client; }

这样测试里调用SmsUtil.reinitForTest(mockProps, mockClient)就能注入mock，不影响生产逻辑。这个方法虽然是为了测试开的口子，但在团队开发中非常实用，能少踩不少集成测试的坑。

8.4 关于静态字段的final修饰符争论

可能有人问：既然setter能赋静态字段，那我把字段定义成private static final再用setter赋值行不行？答案是编译都过不了。final表示这个字段只能赋值一次，而且要求是在声明处或者构造器里初始化（普通类的静态final字段必须在静态代码块中赋值）。setter方法是在运行时才调用的，编译器不允许你这么做。所以setter方案里的静态字段必须是可变的，不能加final。

如果你追求final的不可变效果，就得回到方案三的"构造器持有静态实例"思路，静态字段保存的是实例引用，实例内部的具体依赖可以都是final的。

9. 常见问题速查与独家避坑清单

9.1 静态字段注入为null时的排查顺序

我遇到过不少同事拿着这个问题来问，排查顺序基本是固定的：

第一步：确认类被Spring扫描到。检查类上有没有@Component/@Service/@Configuration等注解，或者是不是在@ComponentScan的扫描路径下面。一个比较好的自检手段：在setter方法里加一行System.out.println或者打日志，如果启动时没有打印，说明类根本没被管理。

第二步：确认方法被识别。@Value或者@Autowired标注的方法是否真的被调用。如果类被扫描到了但是方法没被调用，看看是不是方法签名有问题，比如@Value写法里Spring解析占位符失败导致启动报错（占位符找不到配置项时默认会启动失败，反而更容易排查）。

第三步：确认没有多个Spring上下文。有些老项目用Spring + SpringMVC或者Spring + Spring Boot共存，ContextLoaderListener和DispatcherServlet各创建一个容器，你在一个容器里注入的值可能被另一个容器的setter调用覆盖回null。这种情况最隐蔽，而且很难从日志里看出来。排查方式：在setter里打印一下当前线程的上下文类名，看看有没有多个容器在调。

第四步：确认静态字段没有被其他地方显式置空。有些同事会在代码里随手xxx = null，这就没办法了。

9.2 静态字段在多线程下的可见性

Spring setter方法注入发生在启动阶段，之后静态字段就只读不写了，所以基本不存在并发问题。但如果在运行时通过某种手段（比如动态配置刷新）去修改静态字段，就得考虑可见性问题。Java内存模型不保证静态字段在多线程下的可见性，除非你用volatile或者加锁。稳妥做法：如果静态字段必然会在运行时被更新，声明成private static volatile。虽然大部分场景用不上，但一旦用上，这个细节能帮你省掉很多诡异的偶发问题。

9.3 为什么我推荐尽量少用@PostConstruct方案

有一种常见的方案是：先把依赖注入到实例字段，再在@PostConstruct里赋值给静态字段。比如：

@Component public class SomeHolder { @Autowired private SomeService service; private static SomeService staticService; @PostConstruct public void init() { SomeHolder.staticService = this.service; } }

这个方案能用，但有一个潜在问题：@PostConstruct的执行时机是在Spring完成属性填充之后、Bean初始化阶段。如果你的某个静态方法在Bean初始化之前就被调用了（比如在另一个Bean的构造器里调用，或者某些非常早期的初始化代码），静态字段就是null。而setter方案里，只要依赖的对象属性填充完成，值就一定写进去了。两者在时序上有微妙的差别：setter阶段比@PostConstruct更早。所以如果两者选其一，我选setter方案。

9.4 一个真正干净的终极方案：重新设计

其实从架构角度说，静态属性注入这个需求本身，往往意味着设计上有可以优化的地方。Spring的依赖注入机制鼓励你用组合和实例方法，而不是全局静态状态。如果业务代码全都在Spring容器管理下，最好别把依赖塞进静态方法，而是直接注入Bean。

但现实是，工具类静态方法在很多项目里太常见了，彻底改造的成本很高。所以我的建议是：新代码尽量少写全局静态工具类，老代码用setter方案做最小改动。如果有一天你发现静态方法越来越多，依赖越来越多，那就是时候考虑把工具类改成实例Bean，或者用方案三重构了。

9.5 我的一点实操心得

踩过这个坑之后，我现在写工具类的习惯已经固化了：第一，所有需要配置或依赖的静态工具类，统一用setter注入模式，而且类上明确加@Component便于他人识别；第二，配置项超过3个就建@ConfigurationProperties类，不让@Value散落遍地；第三，测试需要时保留一个reinitForTest的口子。这几条规则让我后面在这个问题上几乎没再花过时间。

最后分享一个容易被忽略的顺带好处：setter注入方案的类也可以被继承和重写。因为它是普通Spring组件，你在测试里可以直接new一个实例，调用setter注入自己的假数据，再验证静态方法逻辑，而不需要真的去启动整个Spring容器。这个灵活性，是直接@Autowired静态字段的方案完全做不到的。