静态内部类只能访问外部类的static成员，不能访问非静态成员；其实例化无需外部类实例，适用于无需隐式引用外部类实例的工具类等场景。
静态内部类能直接访问外部类的哪些成员
静态内部类不能访问外部类的非静态成员，这是最常踩的坑。它只能访问外部类的static字段和static方法，连this引用都没有——因为它不依附于任何外部类实例。
比如外部类有个private static String CONFIG = "dev"，静态内部类可以直接用OuterClass.CONFIG读取；但若写outerInstance.field或调用outerInstance.doSomething()，编译直接报错：non-static variable/method cannot be referenced from a static context。
- 想绕过限制？得显式传入外部类实例作为参数，而不是依赖隐式绑定
- 如果发现静态内部类总在“想办法搞到外部实例”，说明设计可能错了——该用普通内部类或独立类
- 注意：静态内部类的
static块、static字段初始化，只依赖外部类的类加载，和外部类实例生命周期完全解耦
什么时候该用静态内部类而不是普通内部类
核心判断点就一个：这个类是否需要持有对外部类实例的隐式引用。不需要，就用static；需要，才用非静态内部类。
典型场景是工具型辅助类，比如HashMap里的Node、TreeMap里的Entry——它们只封装数据结构逻辑，不操作外部容器的状态；又比如配置解析器里定义的ConfigBuilder，纯做对象构建，不读写外部类的实例字段。
立即学习“Java免费学习笔记（深入）”；
- 用了非静态内部类却从不访问外部实例？内存泄漏风险+额外4~8字节引用开销（每个实例都带
this$0指针） - 用了静态内部类却频繁通过参数传
this？说明它本就不该是“静态”的 - 序列化时，非静态内部类会强制序列化外部类实例，而静态内部类不会——这点在RPC或缓存场景很关键
静态内部类如何被外部代码实例化
语法上不用先创建外部类实例，直接用OuterClass.StaticInner就能构造，就像普通顶层类一样。但它仍属于外部类的命名空间，受访问修饰符约束。
例如public static class Builder可被任意包访问；private static class Helper只能在外部类内部使用；protected static class Cache对子类可见，但对外部包不可见。
- 构造器可以是
public、private等任意修饰，和顶层类规则一致 - 不能有
protected或default（包级）的静态内部类——Java语法不允许，编译报错modifier not allowed - 反射获取类对象要写全名：
Class.forName("com.example.OuterClass$StaticInner")，注意是$不是.
静态内部类与单例、工厂模式的常见混用陷阱
很多人用静态内部类实现单例（“登记式单例”），利用JVM类加载机制保证线程安全。但容易忽略两点：一是类加载时机不可控（首次主动使用才触发），二是如果外部类本身已被加载，静态内部类的static块可能早于预期执行。
更隐蔽的问题是，在OSGi、Spring Boot DevTools等动态类加载环境中，同一个类可能被多个ClassLoader加载，导致静态内部类的单例失效——因为OuterClass$SingletonHolder在不同类加载器下是不同类。
- 不要在静态内部类里缓存跨类加载器的资源（如
DataSource、HttpClient） - 工厂方法返回静态内部类实例时，注意泛型擦除：若写
public static，编译失败——静态内部类无法带外部类的类型参数Outer .Factory create() - Android开发中，避免在
Application类里用静态内部类持Activity引用，即使它是“静态”的，也照样引发内存泄漏
