var只是省略类型声明的语法糖，不能真正推断类型；仅当右侧表达式自解释且类型冗长时才提升可读性，如泛型嵌套、流式调用、明确上下文的Lambda；返回值模糊、基本/包装类混淆、字面量推导、循环及try-with-resources中易引发误解的场景应禁用。
Java 的 var 不能真正“推断类型”来提升逻辑表达力，它只是省略显式类型声明的语法糖；用错反而让代码更难读。
什么时候用 var 真正提升可读性
核心原则：右侧初始化表达式已足够自解释类型，且类型名冗长或重复出现。
- 泛型嵌套类型，如
Map→ 改用>> map = new HashMap(); var map = new HashMap>>(); - 流式链式调用结果，如
var result = list.stream().filter(...).map(...).collect(Collectors.toList());—— 类型藏在collect()里，写全反而干扰主逻辑 - 匿名内部类或 Lambda 上下文明确时，如
var runnable = () -> System.out.println("ok");（前提是方法参数已声明为Runnable）
哪些场景绝对不该用 var
一旦右侧无法一眼看出语义或类型边界，var 就是在埋坑。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 返回值类型模糊的方法调用：
var data = service.getData();—— 你得跳转到getData()才知道是String还是Optional - 基本类型与包装类混淆风险：
var count = Integer.valueOf(42);推出的是Integer，但后续若误用==比较，行为和int count = 42;完全不同 - 涉及数值字面量推导：
var x = 100;→int，var y = 100L;→long，但var z = 100.0;→double，而var w = 100.0f;→float—— 字母后缀稍一漏看，类型就偏了
var 在循环和 try-with-resources 中的实操陷阱
这两处看似简洁，实则最容易掩盖资源生命周期和迭代对象本质。
- 增强 for 循环中：
for (var item : list)合理，但for (var item : map.entrySet())会让item类型变成Map.Entry，如果没注意泛型，后续调item.getKey()时可能误以为是K实际却是Object - try-with-resources：
try (var fis = new FileInputStream("a.txt")) { ... }看似干净，但fis的实际类型是FileInputStream，而接口类型（如AutoCloseable）信息完全丢失 —— 如果后续要调用子类特有方法（比如fis.getChannel()），就得强转，反而更啰嗦
最常被忽略的一点：var 不改变变量的不可变性，也不影响泛型擦除或运行时类型。它只在编译期帮你看不见类型名，但所有类型检查、桥接方法、类型转换规则照旧。过度依赖它，等于把类型契约从代码里抽走，交由 IDE 或脑子临时缓存 —— 而人脑缓存，从来不可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
