var + final 是 Java 10+ 中兼顾简洁性、不可变性与编译期安全的黄金组合：编译器推断精确类型并冻结变量，确保类型安全与不可重赋值，适用于取值、流操作、资源初始化等一次性确定场景。
用 var 声明局部变量，再用 final 修饰它，是 Java 10+ 中兼顾简洁性、不可变性与编译期安全的黄金组合。这不是炫技，而是让代码既“一眼可知意图”，又“编译期锁死行为”的务实写法。
为什么 var + final 是现代 Java 的安全基线
单独用 var 只解决类型冗余问题；单独用 final 虽能防重赋值，但类型声明仍可能冗长或模糊。二者结合后：
- 编译器在声明时就推断出精确类型，并立即冻结该变量——后续任何类型不匹配或重复赋值都会在编译时报错
- 变量名承担语义责任（如
final var userId = user.getId();），类型由编译器兜底，人专注表达“这是什么”，而非“它是什么类型” - IDE 悬停即见真实类型，重构（如重命名、提取方法）完全可靠，无运行时开销
适用场景：哪些地方必须加 final
凡属“定义即确定、后续绝不变更”的局部值，都应默认用 final var：
- 从对象取值：
final var email = user.getEmail();（推断为 String，且 email 不可再指向别处） - 流操作中间结果：
final var activeOrders = orders.stream().filter(Order::isActive).toList();（推断为 List，集合引用不可变） - 资源初始化：
final var mapper = new ObjectMapper();（避免意外重赋值导致 NPE 或状态混乱） - 配置构建：
final var config = Config.builder().timeoutMs(5000).retries(3).build();（Builder 返回明确类型，final 防止中途被覆盖）
避坑要点：不是所有 var 都适合加 final
加 final 的前提是“该变量确实不该变”。若逻辑天然需要重赋值，硬加 final 会破坏可读性甚至导致绕弯写法：
- 循环计数器：
for (final var i = 0; i ❌ 编译失败（i 在循环中被修改） - 状态暂存变量：
final var result = compute(); if (result == null) result = fallback();❌ 编译失败（不能二次赋值） - 正确做法：这类变量保持
var即可，或改用更清晰的语义命名（如var currentRetry = 0;）
与 lambda 和 try-with-resources 的协同写法
final var 在函数式和资源管理上下文中同样自然有力：
- lambda 参数（Java 11+）：
list.forEach((final var item) -> process(item));—— 明确表达“每个 item 在本 lambda 内只读” - try-with-resources：
try (final var in = Files.newInputStream(path)) { ... }—— 资源变量本身不可重赋，final 强化这一契约，也便于 IDE 推断其生命周期 - 注意：lambda 中不能混用（如
(String key, final var value)）—— 要么全显式，要么全用final var
这种写法不增加运行成本，却大幅降低人为失误概率。它把“不可变”从注释或约定，变成编译器强制执行的契约。只要变量语义上是“一次性确定”的，final var 就是最直白、最安全的表达方式。
