接下来，我们将分析这个问题的两种解决方案：一种是应急用的“偏方”，另一种是更推荐的“正解”。
方案一：延迟赋值（仅作技术验证，不推荐生产使用）
如果你只是希望快速跑通一个测试，或者暂时没有时间重构类结构，可以试试这种“绕道而行”的办法：构造时先传入null，后续再手动将内部类实例赋值回去。
public class A {
public B b; // 注意：需设为 public 或提供 setter
public A(B b) {
this.b = b;
}
public class B {
public B() {}
}
}
// 使用方式：
A a = new A(null); // 先绕过构造约束
A.B b = a.new B(); // 基于已有 A 实例创建 B
a.b = b; // 再赋值（需字段可访问或有 setter）
⚠️ 需要提醒的是：这种方案虽然能编译运行，但副作用十分明显——破坏了对象的不可变性和封装性。构造完成后的一段时间内，对象处于“残缺”状态，稍不留神就会引发空指针或并发问题。简而言之，该方法仅适用于调试或极端受限的临时场景，在生产代码中应尽量避免使用。
方案二：使用静态嵌套类（推荐方案）
真正解决问题的思路，是让内部类不再依赖于外部类实例。如何实现？添加static修饰符即可——静态嵌套类不持有外部类引用，可以独立创建，循环依赖自然迎刃而解。
public class A {
private final B b; // 建议 final + private，配合构造注入
public A(B b) {
this.b = b;
}
public static class B { // ✅ 关键：添加 static 修饰符
public B() {}
// 可扩展：支持与 A 协作的逻辑（但不依赖 A 实例）
}
}
这样初始化流程变得清晰简洁：
A.B b = new A.B(); // 无需 A 实例即可创建 A a = new A(b); // 构造时传入已存在的 B
✅ 采用静态嵌套类的优势包括：
- 初始化顺序清晰，从根本上避免了循环依赖；
- B 类可以独立测试、复用，并且支持序列化（非静态内部类默认不支持序列化）；
- 从设计角度看，如果内部类在逻辑上不需要访问外部类的实例成员，它本来就应当被设计为静态类；
- 完美契合《Effective Java》第24条建议：“优先使用静态成员类而非非静态”。
?️ 设计提示：遇到类似的循环依赖问题时，不妨先问自己——这个内部类真的需要持有外部类的引用吗？如果答案是否定的，那么 static 就是更自然、更健壮的选择。
