Spring Boot 的 @Value 静态字段为什么一直是 null

把配置字段改成 static 后，其他类调用方便了，值却一直是 null：

@Value("${app.image-dir}")
private static String imageDir;

Spring 的注入处理会跳过静态字段。即使这个类已经是 Bean、配置键确实存在、应用也完成启动，这种写法仍然收不到值。Spring Boot 3.x 所用的 Spring Framework 6.x 也保留这一规则。

另一个容易混在一起的问题是读取时间：在 main 方法里、SpringApplication.run(...) 之前读取配置，容器还没有创建；在普通字段的初始化表达式里读取注入字段，则字段注入也还没有发生。去掉 static 只能解决其中一部分。

将配置作为实例的构造器参数

如果这个值用于业务服务，让服务接收配置后再工作。下面是一组最小示例，app.image-dir 是图片目录，不包含创建目录或文件访问逻辑：

app.image-dir=/srv/example/images

package com.example.image;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;

@Service
public class ImageService {
    private final String imageDir;

    public ImageService(@Value("${app.image-dir}") String imageDir) {
        this.imageDir = imageDir;
    }

    public String imageDirectory() {
        return imageDir;
    }
}

调用方通过构造器接收 ImageService，再调用实例方法。单构造器不必再标 @Autowired。这个类必须进入组件扫描范围，调用方也应使用容器提供的对象；直接 new ImageService(...) 时，参数由调用方负责，Spring 不会替这次手动创建解析 @Value。

构造器参数在对象创建时就可用，因此同一构造器里拼接路径或构造其他值不会依赖字段注入的先后顺序。若配置缺失且没有默认值，Bean 创建可能报占位符解析失败；这与静态字段被跳过后默默保留 null 是两种现象。

不要为了让启动通过就给实际必需的配置加空字符串默认值。目录为空时，后续路径解析可能落到非预期位置。默认值应由业务需求决定。

启动代码里需要配置时

需要在应用启动后读取值，可以使用容器创建的 ApplicationRunner，而不是在 main 中提前访问静态字段：

package com.example.image;

import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;

@Component
public class ImageStartup implements ApplicationRunner {
    private final ImageService imageService;

    public ImageStartup(ImageService imageService) {
        this.imageService = imageService;
    }

    @Override
    public void run(ApplicationArguments args) {
        String imageDir = imageService.imageDirectory();
        // 在这里使用已注入的目录；示例不创建或修改文件。
    }
}

它展示读取时机，不要求项目再建立一套启动任务。如果已有初始化入口，将依赖传入现有入口即可。

同样要检查这种写法：

@Value("${app.image-dir}")
private String imageDir;

private final String previewDir = imageDir + "/preview";

普通对象初始化时，previewDir 已经计算完，之后给 imageDir 注入新值不会重算它。需要在构造器里根据已解析的参数计算，或者在实际使用时通过方法计算。

非静态 setter 写入静态变量有什么代价

非静态 setter 或构造器可以接收注入值，再由普通 Java 赋值写进静态变量。这能让代码读到值，但并没有使 Spring 支持静态字段注入。

静态变量属于类，多个 ApplicationContext 或并行测试可能覆盖同一份值；在负责赋值的 Bean 初始化前访问，仍可能读到 null。只把字段包装在一个静态 getter 中，也不会解决初始化时间和共享状态。

无法立刻修改的旧工具类，可以由已注入配置的业务对象把值作为方法参数传入。这样可以保留工具方法的静态形式，同时让配置的来源和读取时间明确。

修改后应从正常业务入口确认实例取得预期值，再核对原来提前读取的位置是否已移走。若实例字段依旧为空，继续检查对象是不是容器创建、配置是否加载以及读取时机；不要再通过添加 @PropertySource 掩盖静态注入问题。Boot 默认加载的 application.properties 或 application.yml 也不需要为这件事重复声明一次。