成员内部类必须依附外部类实例存在，其构造强制要求outerInstance.new InnerClass()语法，因编译器自动注入Outer.this引用，导致无法独立实例化，且引发内存泄漏等风险。
成员内部类对外部类实例的强依赖，最直接的体现就在它的实例化语法上——它根本不能脱离外部类对象单独存在。理解这一点，关键不是背规则，而是看清语法背后的设计逻辑。
实例化语法暴露了“隐式持有”的本质
成员内部类的对象创建必须写成：outerInstance.new InnerClass()，而不是 new Outer.Inner()。这个看似繁琐的写法，其实是在强制你承认一个事实：每个 InnerClass 实例内部，都悄悄持有一个指向 outerInstance 的引用（编译器自动注入，名为 Outer.this）。
这种引用不是可选的，是构造时硬编码进字节码的。反编译后能看到，InnerClass 的构造方法实际多了一个 Outer 类型参数，并用它初始化了那个隐藏字段。
为什么不能直接 new？——静态与非静态的根本冲突
成员内部类属于“非静态上下文”，它天然绑定到某个具体的外部类对象。而 new Outer.Inner() 这种写法，语义上等同于调用一个静态构造器，但 Java 规定：非静态内部类没有静态构造入口。
立即学习“Java免费学习笔记（深入）”；
- 它不能有 static 方法或普通 static 字段（static final 常量除外）
- 它的生命周期必须晚于、且依附于外部类实例的生命周期
- 一旦你试图绕过 outer 实例去创建 inner，编译器立刻报错：“No enclosing instance of type Outer is accessible”
从语法反推设计意图：封装与访问特权的代价
正因为它隐式持有外部类实例，所以才能无条件访问 private 字段和方法。这种便利是有代价的：
- 如果 inner 被长期持有（比如放进静态集合、传给异步线程），就会导致 outer 实例无法被 GC 回收——典型的内存泄漏源头
- 序列化 inner 时，outer 实例也会被一并序列化（除非 outer 实现 Serializable）
- 若你发现 inner 其实并不需要访问 outer 的任何非静态成员，那这个强依赖就是冗余的，该考虑改用 static 内部类
验证依赖是否真实存在的简单方式
在 InnerClass 中加一行代码：System.out.println(this instanceof Outer.Inner && Outer.this != null); ——运行必输出 true。再把 inner 提取为静态类试试，这段代码直接编译失败。语法不是约束，是契约；它告诉你：只要用了成员内部类，你就签下了这份“必须带 outer 实例入场”的协议。
