Spring三级缓存仅能解决单例Bean的字段/Setter注入循环依赖，无法处理领域模型隐式双向引用、跨限界上下文强关联及构造期动态绑定等深层循环；须从设计源头通过解耦导航关系、划分限界上下文、重构构造逻辑来根治。
核心思路是：不靠框架兜底，而是从设计源头切断循环依赖的生成条件。Spring 的三级缓存只能解单例 + 字段/Setter 注入的表层循环，而领域模型内部若存在隐式双向引用（比如 Order 持有 Customer，Customer 又反向持有 orders 列表），会在解析阶段就触发 BeanDefinition 加载死锁，连缓存都用不上。
一、识别并消除隐式双向关联
隐式循环常藏在“看似合理”的集合引用或导航属性中。例如：
- 订单实体 Order 中声明
private List<OrderItem> items; - 订单项实体 OrderItem 中又声明
private Order order;
这种结构在 JPA/Hibernate 映射时极易触发双向关联解析循环。解决方式不是加 @JsonIgnore 或 @Transient，而是重构关系语义：
- 将
Order.items改为只读视图（如unmodifiableList），禁止外部修改 - 移除
OrderItem.order字段，改由仓储层（OrderItemRepository.findByOrderId()）按需查询 - 若业务强需导航，引入只读接口（如
OrderView），不参与实体生命周期管理
二、用限界上下文隔离聚合根边界
循环链往往源于跨域建模失当。比如“用户”和“地址”本属不同上下文，却因图方便共用一个 User 类，导致 User.address.province 触发地理服务模块加载，而地理服务又依赖用户权限校验。
- 明确划分限界上下文：用户上下文只含
User核心身份字段；地址上下文独立建模Address，通过 ID 关联 - 聚合根之间仅保留 ID 引用（
userId: UUID），杜绝对象级强引用 - 跨上下文数据获取统一走防腐层（Anti-Corruption Layer），如
AddressService.getByUserId()，而非直接 new 或注入
三、重构构造逻辑，避免运行时动态绑定
有些循环链来自构造期行为，比如工厂类在创建 A 时调用 B 的 builder 方法，而 B 的 builder 又回调 A 的静态方法。
- 把构造逻辑外提到装配层（如 Spring 的
@Configuration类），用明确的初始化顺序控制依赖流向 - 对必须延迟绑定的场景，使用
ObjectProvider<B>或Supplier<B>替代直接注入，让实例化时机可控 - 禁用领域模型中的静态工具方法互相调用，这类调用无法被容器管理，是隐式循环高发区
