多次setter注入导致重复赋值的根本原因是缺乏状态管控和幂等性设计；可通过标志位单次赋值、值一致性比对、@postconstruct延迟生效及依赖注入层降级四种策略协同解决。
多次 Setter 注入导致重复赋值，本质是依赖注入过程中缺乏状态管控和幂等性设计。Spring 默认不校验 setter 是否已被调用，连续注入会覆盖前值，可能引发业务逻辑错乱（如配置被意外重置、状态被反复刷新）。关键不是阻止 setter 调用，而是识别“有效赋值”并拒绝冗余操作。
基于标志位的单次赋值防护
在 setter 内部维护一个私有布尔字段，首次赋值后锁定，后续调用直接返回：
- 适用于明确“只应初始化一次”的属性（如核心配置、连接池实例、单例上下文）
- 需配合 volatile 或 synchronized 防止多线程竞态（尤其在 Bean 初始化早期阶段）
- 注意：不能用于需要运行时动态更新的属性，否则会误拦截合法变更
值一致性比对拦截
在 setter 中对比新旧值，相同则跳过赋值与后续逻辑：
- 使用 Objects.equals(oldValue, newValue) 判定语义相等（支持 null 安全）
- 对集合、数组等复杂类型，建议用 Apache Commons Lang 的 CollectionUtils.isEqualCollection() 或 Arrays.deepEquals()
- 避免仅用 == 比较引用，易漏判内容相同但对象不同的情况
结合 @PostConstruct 做最终确认
将 setter 设为“暂存入口”，真正生效延迟到初始化完成阶段：
- setter 只保存传入值到临时字段（如 _pendingConfig），不触发任何副作用
- 在 @PostConstruct 方法中统一校验、合并、落库，并清空暂存区
- 天然规避多次 setter 的干扰，也便于集中做合法性校验和默认值填充
依赖注入层主动降级处理
从源头减少重复注入机会，而非仅靠 setter 防御：
- 检查 XML 或 @Bean 定义中是否对同一 Bean 多次声明 setter 注入
- 避免混合使用 @Autowired（字段注入）和 setter 注入同一属性，Spring 会按顺序执行，易造成覆盖
- 对第三方库提供的类，若无法修改其 setter，可包装一层代理 Bean，拦截并去重调用
