static内部类更合适：避免命名污染、降低内存开销、支持builder模式、封装静态协作逻辑。
当内部逻辑与外部类高度相关，但又不需要访问外部类的实例成员时，static 内部类比普通顶层类更合适。
避免命名污染，增强语义归属
把仅服务于某个外部类的辅助类（如 Home、Node、Builder）定义为 static 内部类，能明确表达“它属于这个类的一部分”，而不是一个泛用的全局工具。比如 HashMap.Node 不会和用户自定义的 Node 冲突，也不需要额外包路径隔离。
- 类名作用域被限制在外部类内，天然避免重名问题
- 其他开发者一眼看出该类的设计意图和使用边界
- 不暴露到包级命名空间，减少 API 表面复杂度
降低内存开销与泄漏风险
非静态内部类会隐式持有外部类实例引用，而 static 内部类完全独立。在回调、监听器、缓存对象等长期存活场景中，这点尤为关键。
- 例如：Activity 中定义的 Handler 若用非静态内部类，容易导致 Activity 无法回收
- 改用 static 内部类 + WeakReference，可安全持有外部状态
- 频繁创建实例时（如解析 JSON 生成临时节点），static 内部类无额外引用开销
支持 Builder 模式与不可变对象构造
Builder 是 static 内部类最典型的应用——它需灵活配置参数，但最终只依赖静态工厂逻辑，无需绑定某个外部实例。
- Builder 可独立于主类实例存在，调用链清晰（
new Person.Builder().name("A").build()） - 主类保持 final 字段和不可变性，构造过程与实例生命周期解耦
- 编译后仍是独立 class 文件（
Person$Builder.class），不影响运行时结构
封装仅依赖静态资源的协作逻辑
当内部类只需用到外部类的 static 字段、static 方法或常量，且多个外部类实例可共享同一内部类行为时，static 内部类是自然选择。
- 比如配置解析器、序列化策略、状态码映射表等，本身无状态或仅读取静态配置
- 不同
Person实例可共用同一个Person.Home类型定义，无需重复加载 - 比单独建包+public 类更轻量，比 private 顶层类更易维护
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
