Spring Boot 的自动配置能力大量依赖 @EnableXxx 注解，例如 @EnableScheduling 开启定时任务、@EnableAsync 开启异步执行。它们本身并不包含具体实现，而是通过 @Import 把对应的配置类或注册器导入容器。对于环境配置来说，Spring Boot 原生提供的 Environment 接口可以统一读取系统属性、环境变量、配置文件，但如果想实现按模块启用配置加载，就需要自定义一个 @EnableEnvironment 注解来完成整合。
本文会从 @Enable 模块驱动机制出发，逐步实现注解定义、注册器逻辑、属性源加载以及多环境切换，最终让模块化配置以一条注解的方式接入主应用。整个过程不需要引入额外框架，只使用 Spring Boot 本身提供的扩展点即可完成。
一、Spring Boot 的 @Enable 模块驱动机制
Spring Boot 中几乎所有的 @EnableXxx 注解都遵循同一种设计模式：注解本身只负责标记，真正的工作由 @Import 导入的类来完成。比如 @EnableScheduling 会导入 SchedulingConfiguration，而 @EnableAsync 会导入 AsyncConfigurationSelector。@Import 支持三种导入方式：直接导入配置类、导入 ImportSelector 实现、导入 ImportBeanDefinitionRegistrar 实现。
直接导入配置类最简单，适合目标逻辑固定、不需要根据条件动态判断的场景。但环境配置通常需要结合当前激活的 profile、已有的 bean 定义等信息来决定注册哪些组件，因此更推荐后两种方式。其中 ImportBeanDefinitionRegistrar 可以拿到 BeanDefinitionRegistry，允许在运行时手动注册 bean 定义，灵活度最高。
下面是一个简化版的 @EnableScheduling 原理示例，它展示了注解如何通过 @Import 把配置类带入容器：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(SchedulingConfiguration.class)
public @interface EnableScheduling {
}
@Configuration
public class SchedulingConfiguration {
@Bean
public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
return new ScheduledAnnotationBeanPostProcessor();
}
}
当启动类标注 @EnableScheduling 后，ConfigurationClassParser 会在解析配置类时读取 @Import 元数据，并递归处理被导入的类。这个机制同样适用于自定义 @EnableEnvironment，我们可以通过它导入一个配置注册器，完成环境配置模块的挂载。
二、定义 EnableEnvironment 注解与注册器
自定义 @EnableEnvironment 的目标是让主应用可以使用一条注解启用某个模块的环境配置能力。先定义注解本身，保留 profiles 属性用于指定需要激活的配置环境，默认值为空表示跟随 Spring Boot 当前激活的 profile。
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(EnvironmentRegistrar.class)
public @interface EnableEnvironment {
String[] profiles() default {};
}
接着实现 EnvironmentRegistrar，它负责在容器启动阶段注册一个与环境配置相关的 bean。这里不直接注册 Environment 本身，因为 Spring 容器已经管理了一个 ConfigurableEnvironment 实例。我们通常注册一个持有环境属性的配置组件，或者注册一个后置处理器来完成属性绑定。
public class EnvironmentRegistrar implements ImportBeanDefinitionRegistrar {
@Override
public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
Map<String, Object> attrs = importingClassMetadata
.getAnnotationAttributes(EnableEnvironment.class.getName());
String[] profiles = attrs == null ? new String[0] : (String[]) attrs.get("profiles");
GenericBeanDefinition definition = new GenericBeanDefinition();
definition.setBeanClass(EnvironmentConfig.class);
definition.getPropertyValues().add("profiles", profiles);
registry.registerBeanDefinition("environmentConfig", definition);
}
}
这里的 EnvironmentConfig 可以是一个简单的配置类，负责打印当前环境信息或触发属性源刷新。通过读取注解元数据中的 profiles 属性，我们可以把参数传递给后续的配置加载逻辑，避免在主应用中硬编码 profile 名称。
需要注意的是，ImportBeanDefinitionRegistrar 的执行时机早于大部分 bean 的实例化，但晚于配置类解析。因此如果需要在 EnvironmentPostProcessor 阶段获取注解信息，通常无法直接使用这里注册的 bean，应该转而使用 spring.factories 扩展点，这一点会在下一节说明。
三、整合 EnvironmentPostProcessor 加载属性源
Spring Boot 在启动早期会通过 EnvironmentPostProcessor 对 ConfigurableEnvironment 进行二次加工，这比普通的 bean 注册更早。利用这个机制，我们可以在所有配置类解析之前把模块内的 properties 文件添加到 PropertySource 列表中，从而让 @Value 注入和 Environment#getProperty 都能读取到这些配置。
public class ModuleEnvironmentPostProcessor implements EnvironmentPostProcessor {
@Override
public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
String[] activeProfiles = environment.getActiveProfiles();
String profile = activeProfiles.length > 0 ? activeProfiles[0] : "default";
Resource resource = new ClassPathResource("config/module-" + profile + ".properties");
if (!resource.exists()) {
return;
}
try {
Properties properties = new Properties();
properties.load(resource.getInputStream());
environment.getPropertySources().addLast(
new PropertiesPropertySource("moduleProperties", properties)
);
} catch (IOException e) {
throw new IllegalStateException("加载模块环境配置失败", e);
}
}
}
这段代码根据当前激活的 profile 加载对应的配置文件，比如 dev 环境加载 config/module-dev.properties，prod 环境加载 config/module-prod.properties。addLast 方法将属性源追加到末尾，意味着当主配置与模块配置出现同名 key 时，主配置的优先级更高。如果希望模块配置覆盖主配置，可以改用 addFirst。
为了让 Spring Boot 发现这个处理器，需要在 META-INF/spring.factories 中声明：
org.springframework.boot.env.EnvironmentPostProcessor=com.example.config.ModuleEnvironmentPostProcessor
通过 spring.factories 加载的 EnvironmentPostProcessor 不依赖 @EnableEnvironment 注解，它会无条件执行。如果希望处理器仅在主应用标注了 @EnableEnvironment 时才生效，可以在处理器内部读取系统属性或通过 application 参数检查主类上的注解。但受限于启动顺序，这种检查并不直观。更常见的做法是让 @EnableEnvironment 控制业务配置 bean 的注册，而 EnvironmentPostProcessor 只负责提供底层属性源，二者配合实现完整的可插拔环境配置模块。
四、多环境切换与测试验证
完成注解、注册器和属性源处理器的编写后，可以在主应用类上标注 @EnableEnvironment，并通过 application.yml 切换 profile 来观察不同环境下配置值的变化。主应用启动后直接获取 module.id 和 module.name 两个属性，验证模块配置是否已经合并到当前 Environment。
@SpringBootApplication
@EnableEnvironment(profiles = "dev")
public class Application {
public static void main(String[] args) {
ConfigurableApplicationContext context = SpringApplication.run(Application.class, args);
Environment environment = context.getBean(Environment.class);
System.out.println("module.id=" + environment.getProperty("module.id"));
System.out.println("module.name=" + environment.getProperty("module.name"));
}
}
假设 config/module-dev.properties 中配置了 module.id=dev-001、module.name=开发环境，当 application.yml 中设置 spring.profiles.active=dev 时，启动输出会包含这些值。如果切换到 prod，处理器会加载 module-prod.properties，不需要修改业务代码。
实际项目中还应该注意几个细节。第一，EnvironmentPostProcessor 中不要依赖尚未准备好的 bean，因为它执行得非常早；第二，多个模块都声明 EnvironmentPostProcessor 时，执行顺序由 @Order 注解或 Ordered 接口控制，避免属性源覆盖顺序不符合预期；第三，addLast 和 addFirst 的选择直接影响配置优先级，要根据业务场景明确主配置和模块配置的覆盖关系。
通过自定义 @EnableEnvironment 注解，再结合 @Import 模块驱动和 EnvironmentPostProcessor 早期扩展点，可以把分散的模块配置整理成可插拔、可切换的环境配置单元。这种方式非常适合多 starter 项目、多租户配置或者需要按环境动态加载不同资源文件的场景。
Spring BootEnableEnvironment环境配置修改时间：2026-08-27 13:09:30