@ConditionalOnCloudPlatform是Spring Boot 2.1+原生云平台感知核心注解，通过自动检测运行时环境（如AWS/Azure类路径、环境变量、元数据端点）实现无需profile的平台识别；配合@ConditionalOnClass与@ConditionalOnProperty可精准控制云服务客户端加载，并需注意Bean冲突、加载时机及自定义Condition的超时降级。
@ConditionalOnCloudPlatform 是最直接的切入点
Spring Boot 从 2.1 开始原生支持云平台感知，@ConditionalOnCloudPlatform 就是专为此设计的注解，它不依赖配置文件或 profile，而是通过检测运行时环境特征（如系统属性、环境变量、类路径资源）自动识别 AWS、Azure、Cloud Foundry 等平台。
常见误用是把它和 @Profile 混用——比如写成 @Profile("aws") @ConditionalOnCloudPlatform(CloudPlatform.AWS)。这反而会破坏条件逻辑：profile 是人工指定的，而 @ConditionalOnCloudPlatform 的价值恰恰在于「自动发现」。只要应用跑在 EC2 实例或 Azure VM 上，且满足其检测规则，注解就会生效，无需额外激活 profile。
它的底层检测逻辑包括：
• AWS：检查是否存在 com.amazonaws.services.ec2.AmazonEC2 类 + 环境变量 AWS_REGION 或系统属性 aws.region；
• Azure：检查是否存在 com.azure.resourcemanager.AzureResourceManager 类 + 环境变量 AZURE_ENVIRONMENT 或文件 /var/lib/waagent/GoalState.xml（Azure Linux Agent 特征）。
@ConditionalOnClass + @ConditionalOnProperty 组合用于细粒度服务发现客户端选型
光识别云平台还不够，不同云厂商的服务发现机制差异很大：AWS 主推 ECS Service Connect / Cloud Map，Azure 则倾向使用 Azure Service Fabric 或 App Configuration + DNS。这时需要组合条件，避免硬编码或启动失败。
例如，为 AWS 启用 aws-servicediscovery 客户端，但仅当该 SDK 在 classpath 且配置项启用时才加载 Bean：
@Bean
@ConditionalOnCloudPlatform(CloudPlatform.AWS)
@ConditionalOnClass(name = "software.amazon.awssdk.services.servicediscovery.ServiceDiscoveryClient")
@ConditionalOnProperty(name = "cloud.service-discovery.enabled", havingValue = "true", matchIfMissing = false)
public ServiceDiscoveryClient awsServiceDiscoveryClient() {
return ServiceDiscoveryClient.create();
}
同理，Azure 场景下可这样写：
@Bean
@ConditionalOnCloudPlatform(CloudPlatform.AZURE)
@ConditionalOnClass(name = "com.azure.resourcemanager.appconfiguration.AppConfigurationManager")
@ConditionalOnProperty(name = "azure.appconfig.enabled", havingValue = "true")
public AppConfigurationClient azureAppConfigClient() {
return new AppConfigurationClientBuilder()
.connectionString(System.getenv("AZURE_APPCONFIG_CONNECTION_STRING"))
.buildClient();
}
注意点：
• @ConditionalOnClass 的 name 必须是完整类名字符串，不能写成 AppConfigurationManager.class（那是编译期引用，会导致 jar 缺失时直接 ClassDefNotFound）；
• @ConditionalOnProperty 建议显式设 matchIfMissing = false，避免因配置遗漏导致意外启用；
• Azure 的连接凭据尽量从环境变量读取，而非配置文件，符合云平台安全最佳实践。
自定义 Condition 处理混合云或灰度场景
真实生产环境常有混合部署：部分服务在 AWS，部分在 Azure，甚至跨云调用。此时 @ConditionalOnCloudPlatform 无法区分「当前服务实例归属哪朵云」，因为它只判断「是否在某云上运行」，不保证「所有实例都属同一云」。
你需要一个更精准的判定逻辑，比如读取 Kubernetes Downward API 注入的标签、或查询云元数据服务返回的 instance-id 所属区域：
• 创建 AzureOrAWSCondition 实现 Condition 接口，在 matches() 中调用 http://169.254.169.254/metadata/instance（Azure）或 http://169.254.169.254/latest/meta-data/instance-id（AWS）；
• 使用 @Conditional(AzureOrAWSCondition.class) 替代原生注解；
• 注意超时与 fallback：元数据服务不可达时，应降级为查环境变量（如 CLOUD_PROVIDER=azure），否则容器启动会卡住。
这种自定义方式绕过了 Spring Boot 的自动缓存机制（OnCloudPlatformCondition 结果会被缓存），所以每次匹配都会重新执行 HTTP 请求——必须加本地缓存或设置合理超时（建议 ≤ 2s）。
Bean 冲突与加载顺序的关键细节
当 AWS 和 Azure 的服务发现 Bean 都被声明为 @Primary，又同时满足条件（比如测试环境 mock 了两个元数据端点），Spring 容器会抛出 NoUniqueBeanDefinitionException。这不是条件注解失效，而是条件判定后 Bean 注册阶段的冲突。
解决方法只有两个：
• 显式排除：在非目标云环境下，用 @ConditionalOnMissingBean 包裹另一套实现；
• 分离接口与实现：定义 ServiceDiscoveryClient 接口，让 AWS/Azure 实现类分别带 @ConditionalOnCloudPlatform，再通过 @Qualifier("awsClient") 显式注入，避免 @Primary 冲突。
最容易被忽略的是自动配置类的加载时机：如果你把云平台适配逻辑写在用户自定义的 @Configuration 类里，而该类又被 @Import 进某个 @EnableAutoConfiguration 类，那么它的 @ConditionalOnBean 或 @ConditionalOnMissingBean 可能早于 Spring Boot 自动配置执行，导致判断不准。稳妥做法是——把这类适配逻辑放在独立的 auto-configuration module 中，并在 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 里声明，确保它参与标准自动配置排序流程。
