该用静态还是非静态取决于访问需求：需访问外部类实例成员则用非静态，仅用静态成员或工具功能则优先static，以避免内存泄漏、支持序列化并提升性能。
内部类该用静态还是非静态？看访问需求
非静态内部类（成员内部类）能直接访问外部类所有字段和方法，包括私有的；静态内部类则只能访问外部类的静态成员。如果辅助功能需要操作外部类实例状态，比如封装一个针对当前对象的校验器，就用非静态；如果只是工具性质，比如定义一组常量或通用解析逻辑，优先选 static——它不持有外部类引用，避免内存泄漏，也更轻量。
- 非静态内部类隐式持有一个外部类实例引用，可能导致
OutOfMemoryError（尤其在长生命周期对象中持有短生命周期外部实例时） - 静态内部类可独立于外部类实例存在，能被序列化，也能作为
Comparator或Supplier的简洁实现 - 匿名内部类和局部内部类无法声明为
static，但它们本身作用域受限，风险较低
什么时候不该用内部类？警惕过度嵌套
内部类不是组织代码的万能解。当辅助逻辑开始承担多个职责、需要被其他类复用、或内部类自身变得超过 50 行时，它已经越界了。Java 编译后每个内部类都会生成独立的 .class 文件（如 Outer$Helper.class），调试时堆栈里会出现一串 $ 符号，排查成本上升。
- 外部类已有较多内部类时，IDE 导航变慢，
Find Usages结果混杂 - 单元测试难以单独覆盖非静态内部类，因为必须先构造外部类实例
- 若辅助功能涉及泛型推导（如
new Helper()），非静态内部类会因外围类型擦除导致编译错误，此时应改用静态 + 显式类型参数
匿名内部类还在用？优先考虑 Lambda 和私有方法
JDK 8 后，绝大多数只实现单个函数式接口的匿名内部类场景，都可以用 Lambda 替代。比如事件监听、简单 Runnable、Comparator。但 Lambda 无法访问非 final 局部变量，也不能定义新字段或构造逻辑——这时若只是封装几行重复代码，一个私有方法比匿名内部类更清晰。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- Lambda 是语法糖，本质仍是函数式接口实例，不改变调用链路；而匿名内部类会生成新类，增加类加载开销
- 私有方法天然支持重载、文档注释、断点调试；内部类要加
private修饰符还得额外写private static class - 如果匿名内部类里调用了外部类的
this，换成 Lambda 后需确认是否仍需访问实例状态——否则可能引入空指针
内部类访问外部类私有成员，真的安全吗？
Java 允许非静态内部类直接访问外部类的 private 字段和方法，编译器会在字节码层面生成桥接方法（bridge methods）或包级访问的合成方法。这看似方便，实则模糊了封装边界：一旦外部类重构私有 API，内部类会一起失效，且这种依赖不会在 IDE 中高亮提示。
立即学习“Java免费学习笔记（深入）”；
- 编译后的桥接方法在反射中可见，可能被误用，破坏设计意图
- 在模块化（JPMS）环境下，若外部类在不同模块，即使
private，内部类也可能因模块导出规则受限而无法编译 - 更稳妥的做法是：对外暴露必要的
package-private方法（无修饰符），或通过构造参数传入所需数据，把“访问权”显式化
内部类不是语法糖，它是 Java 封装模型的一部分；用得越顺手，越要留意它悄悄绕过的那层访问控制。
