应优先使用 private static 内部类并显式传参，避免非静态内部类隐式持有外部实例引发内存泄漏；default 修饰符易掩盖泄漏风险；Lambda 需避免捕获 this 或短生命周期对象。
访问修饰符本身不直接防止内存泄漏，但它能帮你控制引用关系的可见性与生命周期边界，从而间接降低因内部类误用导致的泄漏和权限混乱风险。关键不是“用对修饰符”，而是理解修饰符如何影响编译器生成的引用结构，并配合设计约束。
非静态内部类必须慎用 private/protected —— 它们会隐式绑定外部实例
private 或 protected 的非静态内部类，看似封装严密，实则隐患最大：编译器会自动为其注入 this$0 字段，强持有外部类实例。一旦这个内部类被线程、静态缓存或回调框架长期持有（比如作为 Runnable 提交到全局线程池），外部类就无法被回收。
- 即使声明为 private class Inner，只要它非 static，就一定持外部引用
- protected 内部类更危险——子类可能在不同包中继承它，无意中延长引用链
- 真正安全的做法是：若需内部逻辑，优先声明为 static private class，再按需传参
static + private 是最安全的组合，但要配合显式数据传递
static 内部类不生成 this static 内部类不生成 this$0，与外部类实例完全解耦。加上 private 修饰，既限制了使用范围，又避免了意外暴露。但它不能直接访问外部类的非静态成员——这反而是优势，迫使你明确哪些数据真正需要传递。
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 构造时只传必要字段：
new StaticTask(userId, timeoutMs)，而非new StaticTask(this) - 若需调用外部方法，可传入接口或 Consumer，而不是整个对象
- 避免在 static 类里缓存 Context、Activity 等短生命周期对象的强引用
default（包级私有）修饰符容易掩盖泄漏源头
把内部类设为 default（不写任何修饰符），看起来“仅限本包使用”，但实际在 Android 或模块化项目中极易引发跨组件泄漏。例如，一个 default 的非静态内部类被工具类或测试代码引用，就会把 Activity 实例悄悄带到测试线程里。
- default 不等于“安全”，只是“不报错”；它让引用链更隐蔽，调试更困难
- 尤其警惕 default + 非 static + 被静态变量持有 的三重组合，这是典型泄漏模板
- 建议统一用 private static，或明确 public static 并配 Javadoc 说明用途
Lambda 表达式比匿名内部类更可控，但仍有陷阱
Lambda 本身不生成独立 class 文件，也不带 this$0，但它在捕获实例变量或方法引用时，仍会隐式持有外部对象。例如 view.setOnClickListener(v -> doSomething()) 是安全的，但 view.setOnClickListener(this::handleClick) 就等价于持有 this 引用。
- 优先用无状态 Lambda：
() -> saveData()，不依赖外部实例字段 - 避免 obj::method 形式的方法引用，除非 obj 是单例或长生命周期对象
- 在 Activity/Fragment 中，用 view.setOnClickListener(v -> { ... }) 比用 this::xxx 更易审查引用关系
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
