非静态内部类能直接访问外部类私有成员但必须依附实例；静态内部类无外部实例引用，适用于纯工具逻辑；匿名内部类易致内存泄漏，应谨慎使用。
非静态内部类能直接访问外部类私有成员，但必须依附于外部类实例
这是最常被误用的点：很多人以为只要把类写在外部类里面，就能天然“隔离”逻辑。其实只有 非静态内部类 才持有隐式 this 引用，才能读写 private int count、调用 updateStatus() 这类非静态成员。静态内部类做不到——它连外部类的实例都没有。
常见错误现象：
- 编译报错
Cannot reference a non-static field from a static context - 运行时
NullPointerException，因为误以为静态内部类能自动拿到外部实例
使用场景很明确：当你要封装的逻辑必须频繁修改或读取外部类的实例状态时，比如一个订单类里的支付校验器、一个 UI 组件里的事件处理器。
实操建议：
- 把内部类声明为
private class Validator，不暴露给任何外部代码 - 不要在内部类里定义
static方法（除非是static final常量） - 如果外部类字段会被多线程修改（如
int retryCount），内部类访问时需同步或改用AtomicInteger，内部类本身不提供线程安全
静态内部类适合纯数据结构或工具逻辑，且无内存泄漏风险
如果你写的内部类只是解析 JSON 片段、校验字符串格式、或封装一组常量，它根本不需要知道外部类当前的状态——那就该用 static class Parser。它不持有外部类引用，不会阻止 GC，编译后也是独立的 Outer$Parser.class 文件。
性能与兼容性影响：
- JDK 8+ 中，静态内部类可直接通过
Outer.Parser访问，无需先 newOuter() - Android 开发中，Activity 内部若用非静态内部类做异步任务，Activity 退出后仍被持有 → 内存泄漏；换成静态内部类 + 构造传参，问题消失
实操建议：
- 用
static class Config封装配置项，比如public static final int TIMEOUT_MS = 5000 - 若需访问外部类实例字段，别硬扛，显式传参：
new StaticTask(outerInstance.getData()) - 避免在静态内部类里偷偷持有一个
WeakReference<outer></outer>并在 null-check 后强转调用——这反而增加复杂度，不如直接用非静态
匿名内部类只该用于一次性回调，别让它长期存活
像 button.addActionListener(new ActionListener() { ... }) 这种写法，本质就是个非静态内部类实例。它能访问方法内的 final 或 effectively final 变量，也隐式持有外部类引用。问题在于：一旦你把它塞进线程池、缓存起来、或注册为全局监听器，外部类就可能永远无法回收。
常见错误现象：
- Swing 应用中 JFrame 关闭后内存不释放
- Android 中 Fragment 销毁后，其内部匿名 Handler 仍在发消息，导致崩溃
实操建议：
- 只在事件驱动、生命周期明确的场景用，比如单次点击、一次 HTTP 回调
- 需要复用？提取成命名的
static class ClickHandler，或用 lambda（前提是不捕获实例字段） - 若必须捕获局部变量，确保它不包含对外部类实例的强引用链（例如别传
this::onSuccess）
内部类不是万能解：比私有方法重，比 package-private 类严
很多开发者一看到“封装”，就本能想套一层内部类。但如果你的逻辑只是简单校验、计算或流程分段，用 private void validateInput() 更直白。内部类真正值得上的时候，是它需要维护自己的状态、响应多次回调、或构成完整行为闭环——比如一个解析器要记住当前偏移、缓冲区、解析阶段。
容易被忽略的关键点：
- 内部类对象和外部类实例的生命周期是绑定的（非静态情况下），这不是语法糖，是 JVM 实际持有的引用关系
- IDE 有时会自动补全
new Outer.Inner()，但你得意识到这背后生成的是outerInstance.new Inner()，不是无代价的 - 单元测试时，内部类不能直接 new，必须先构造外部类——这会让测试变重，若逻辑真够独立，不如拆成 package-private 类
