本文介绍如何结合 @Profile 和 @Primary 注解，在不修改第三方库代码的前提下，仅通过本地配置即可安全替换其提供的 Bean（如 SuperClient），并防止误用于非开发环境。
本文介绍如何结合 `@profile` 和 `@primary` 注解，在不修改第三方库代码的前提下，仅通过本地配置即可安全替换其提供的 bean（如 `superclient`），并防止误用于非开发环境。
在 Spring Boot 项目中，当依赖的第三方库自动注册了某个接口（如 SuperClient）的实现 Bean，而你又无法修改该库源码或其配置时，本地开发阶段常需提供一个轻量、模拟或调试友好的替代实现。此时，@Profile("dev") 与 @Primary 的组合是一种简洁、可靠且符合 Spring 容器语义的标准方案。
✅ 核心原理：
- @Profile("dev") 确保该 Bean 仅在激活 dev 配置文件时被加载；
- @Primary 在同一类型（SuperClient）存在多个候选 Bean 时，优先选择该 Bean 进行自动注入；
- Spring 容器在启动时会根据 profile 过滤 Bean 定义，因此即使第三方 Bean 始终存在，只要它未被 @Profile 限定（即默认全局生效），你的 @Primary + @Profile("dev") 实现就会在 dev 环境中“胜出”。
? 推荐实现方式（可直接提交至团队仓库）：
@Component
@Primary
@Profile("dev")
public class LocalDevSuperClient implements SuperClient {
private static final Logger log = LoggerFactory.getLogger(LocalDevSuperClient.class);
@Override
public void doSomething() {
log.warn("DEV ONLY usage: If found in any non-prod or prod environment, please log as a bug");
// 模拟/简化逻辑，例如返回 mock 数据、调用本地 stub 服务等
}
// 其他方法实现...
}⚠️ 关键注意事项：
- 环境隔离必须严格：确保生产环境（如 prod）绝不激活 dev profile。建议在 application-prod.yml 中显式设置 spring.profiles.active: prod，并在 CI/CD 流程中校验启动参数（如禁止 -Dspring.profiles.active=dev,prod）。
- 避免 profile 冲突：若使用复合 profile（如 spring.profiles.active=dev,feature-x），请确认 feature-x 不会意外启用其他冲突 Bean；必要时可改用 @Profile("!prod") 配合日志防护（但不推荐替代 dev 显式声明）。
- 增强防御性提示：如示例中的日志警告，可在所有公共方法中加入运行时检查（例如 if (!EnvironmentUtils.isDevelopment()) { throw new IllegalStateException("..."); }），进一步防止误用。
- IDE 与构建工具协同：建议在团队 IDE 启动配置中默认指定 -Dspring.profiles.active=dev，并在 Maven/Gradle 构建脚本中为 compile 或 test 阶段排除 dev profile，确保打包产物纯净。
✅ 总结：该方案无需侵入第三方代码、无需全局 @Qualifier 改写、不依赖 @ConditionalOnMissingBean（因其不可控于外部 Bean），是 Spring 原生支持、语义清晰、易于审查和维护的最佳实践。将此类类纳入版本库，能显著提升团队本地开发一致性与启动效率。
