在spring boot中安全替换依赖需用装饰器模式：实现相同接口、构造器注入委托对象、用@primary或@qualifier精准控制注入，避免循环依赖与覆盖；动态场景可借助applicationcontext手动组装装饰链。
要在 Spring Boot 中用服务装饰器安全替换原有依赖，关键不是“删掉旧 Bean”，而是让容器在注入时自动选用你提供的装饰器实例——这需要明确的装配策略和时机控制，而非粗暴覆盖。
明确装饰目标与接口契约
装饰器必须实现与原服务完全一致的接口（如 MessageService），且不能改变方法签名。Spring 依赖注入只认类型（或 name），不关心实现类名。若原服务是 @Service 声明的单例 Bean，你的装饰器也应声明为 @Service 或通过 @Bean 注册，确保能被容器识别。
- 避免使用字段注入（
@Autowired private MessageService delegate;），它会导致循环依赖或空指针——装饰器本身要注入被装饰对象，而该对象又可能间接依赖装饰器 - 推荐构造器注入：装饰器构造函数接收原始服务作为参数，清晰表达依赖关系
- 接口必须定义完整，包括所有业务方法；否则运行时调用缺失方法会抛
UnsupportedOperationException
用 @Primary 精准引导注入选择
当容器中存在多个同类型 Bean（原始服务 + 装饰器）时，@Primary 是最轻量、最可控的指定方式。它告诉 Spring：“在未显式指定 @Qualifier 的地方，优先选我”。
- 给装饰器类加上
@Primary，例如：@Service @Primary public class LoggingMessageServiceDecorator implements MessageService { ... } - 原始服务保持普通
@Service，不加@Primary - 所有直接按接口注入的地方（如
private final MessageService service;）将自动获得装饰器实例 - 若某处确实需要原始服务（比如装饰器内部委托），可通过
@Qualifier("originalMessageService")显式获取（需提前为原始 Bean 指定 name）
避免全局覆盖，用 @Qualifier 隔离不同场景
一个系统里常有多种装饰需求（日志、重试、缓存），全靠 @Primary 无法区分。此时应结合 @Qualifier 和命名 Bean 实现多版本共存。
- 为每个装饰器指定唯一 name：
@Service("loggingMessageService")、@Service("retryableMessageService") - 原始服务也命名：
@Service("basicMessageService") - 业务类中按需注入：
@Resource(name = "loggingMessageService") private MessageService logger;或@Autowired @Qualifier("retryableMessageService") private MessageService retryer; - 这样既不干扰其他模块，又能灵活组合，比如先重试再日志：
@Service("retryThenLogMessageService")内部同时注入两个装饰器
动态装饰链：用 ApplicationContext 手动组装
对需要运行时决定装饰顺序的场景（如灰度开关、配置驱动），不宜靠注解静态装配。应改用 ApplicationContext.getBean() 动态构建装饰链。
- 定义工厂方法：
public MessageService buildDecoratedService(String strategy) { ... } - 根据策略字符串创建不同组合：
new LoggingDecorator(new RetryDecorator(basicService)) - 所有装饰器类不加
@Service，仅作为普通 POJO；原始服务仍由容器管理，供工厂获取 - 工厂方法本身可标记
@Bean并设为@Scope("prototype")，确保每次获取都是新链 - 此方式彻底规避了 Bean 定义冲突，也便于单元测试中传入 Mock 原始服务
