非静态内部类隐式持有外部类强引用（this$0），易致内存泄漏；静态内部类无此引用，更安全高效。应优先使用静态内部类，需访问外部状态时显式传入WeakReference。
成员内部类隐式持有 this$0 引用，直接导致强引用链
每个非静态内部类实例在编译后都会被注入一个隐藏字段 this$0，它是一个对外部类实例的强引用。这个字段不是你写的，是 javac 自动加的，躲不掉。
常见错误现象：Activity 已 finish()，但后台线程还在执行内部类回调，Activity 无法 GC；或者把内部类对象放进静态 Map 或线程池，整个外部类实例就被钉在堆里。
- 哪怕内部类代码里一句
this都没写，this$0依然存在 - 不能通过序列化单独保存非静态内部类实例（会抛
java.io.NotSerializableException） - 无法在
static方法中直接new Outer.Inner()，编译报错：no enclosing instance
静态内部类没有 this$0，内存更轻、GC 更干净
static 修饰的内部类在字节码层面完全不依赖外部类实例：JVM 不生成 this$0 字段，也不要求先有 Outer 实例才能创建 Outer.StaticInner。
性能与兼容性影响：每个静态内部类实例省下 4–8 字节（64 位 JVM 引用大小），看似微小，但在高频创建场景（如网络响应 DTO、Builder 实例）下可累积可观收益；更重要的是，它不会拖住外部类生命周期。
立即学习“Java免费学习笔记（深入）”；
- 创建方式直接：
new Outer.StaticInner()，无需外部类对象 - 只能访问外部类的
static成员，比如public static final String TAG可用，private int count直接编译失败 - 若真需要访问外部类状态，应显式传入
WeakReference<Outer>，而非依赖隐式引用
编译期就能发现访问权限问题，别等运行时泄漏才排查
静态内部类访问非静态成员时，错误发生在编译阶段——这是最友好的提示时机。而内存泄漏是运行时问题，往往要等 OOM 或 MAT 分析堆快照才发现。
容易踩的坑：static 内部类里误写 instanceField，IDE 报红立刻修正；但反过来，非静态内部类被静态集合持有，编译完全通过，问题只在长时间运行后暴露。
- 不确定要不要
static？先写成static，编译报错说“无法引用非静态变量”，再改——比修复线上内存泄漏成本低得多 - 匿名内部类（如
new Runnable() { ... }）默认是非静态的，只要出现在非静态方法里，就自动持有所在实例引用 - Android 中
Handler、AsyncTask（已废弃但仍有存量）、自定义Callback是高危区，优先用static + WeakReference
真正决定内存占用的不是“类本身”，而是引用链是否可控
静态内部类对象本身不比非静态的“更小”，关键差异在于它不制造意外的强引用链。一个 static 类里存着 byte[10MB]，照样吃内存；但只要它不绑着 Activity，Activity 就能及时回收。
复杂点在于：有些场景看似必须用非静态内部类（比如要修改外部类私有字段），但其实可以通过回调接口、事件总线或显式弱引用来解耦。别让“方便访问”掩盖了生命周期失控的风险。
