try-with-resources 语句中资源不能为 null，因语法强制要求声明时必须初始化为非 null 的 AutoCloseable 实例；编译器禁止 null 初始化、赋值语句或未初始化变量，自定义 close() 方法才需内部判空。
try-with-resources 语句中，**资源不能为 null**——这不是“遇到 null 怎么处理”的问题，而是语法和机制层面的硬性限制：声明在 try 括号内的资源变量必须在声明时完成初始化，且编译器要求该表达式必须产生一个非 null 的 AutoCloseable 实例。
资源声明必须是有效初始化表达式
以下写法是非法的，编译直接失败：
❌ 编译错误（无法通过）try (FileInputStream fis = null) { ... } // 报错：The resource type 'FileInputStream' does not permit a null initializer
Java 规范明确禁止在 try-with-resources 括号中使用 null 初始化。资源变量默认具有 final 语义，且初始化必须是确定的、可求值的构造调用（如 new FileInputStream(...)），不能是字面量 null 或未初始化变量。
立即学习“Java免费学习笔记（深入）”；
常见误操作：把资源提前声明再传入
有人试图绕过限制，先声明 null 变量，再在 try 中“复用”，例如：
FileInputStream fis = null;
try (fis = new FileInputStream("a.txt")) { ... }
这在 Java 中根本不是合法语法 —— try 括号内只接受 声明+初始化（如 FileInputStream fis = new FileInputStream(...)），不支持赋值语句。若写成这样，编译器报错：not a valid resource declaration。
真正可能“出现 null”的场景及应对
唯一可能接触 null 的情况，是自定义资源类中 close() 方法内部逻辑依赖某个字段，而该字段因异常或构造失败为 null。但注意：这属于资源自身实现缺陷，不是 try-with-resources 的责任范围。
例如：
- 构造函数抛出异常 → 资源对象根本不会被创建，也就不会进入 try-with-resources 管理流程；
- 资源对象已成功创建，但其内部某成员为 null →
close()方法需自行判空，否则 NPE 会在关闭时抛出（该异常会被抑制或成为主异常，取决于上下文）。
所以，正确的做法是：在自定义 AutoCloseable 实现中，close() 方法应健壮处理内部状态，比如：
public void close() { if (channel != null) channel.close(); }
对比传统 finally 的误区澄清
有人拿传统写法中 “if (fis != null) fis.close()” 类比，误以为 try-with-resources 也需做 null 检查。这是混淆了层级：前者是对引用变量做防御，后者是对资源生命周期做契约保证。try-with-resources 管理的对象一定是成功构造出来的实例，null 不在其设计模型内。
