var只能推导出编译器能从右侧表达式唯一确定的具体类型，不能推null、字段/返回值类型、lambda参数（Java11+需括号），推导结果为实际运行时类型而非父类。
Java 里 var 到底能推什么类型？
var 不是动态类型，它只是编译器帮你省掉左边重复写的类型名。编译器必须从右边表达式立刻、唯一、无歧义地推断出具体类型，否则报错。
- 右边不能是
null（没类型信息，编译器推不出） - 不能用于字段声明、方法返回值、catch 参数等上下文缺失的地方
- 不能用于 lambda 表达式参数（
var x -> x.toString()在 Java 11+ 才支持，且需显式加括号） - 推导结果是实际运行时类型，不是父类或接口：
var list = new ArrayList<String>(); // list 类型是 ArrayList<String>，不是 List<String>
- 多态丢失风险：如果后续想调用
ArrayList特有方法（比如ensureCapacity），用var就得强转，不如直接写明类型
泛型钻石操作符 <> 和 var 的区别在哪？
<> 是给构造器用的，只解决泛型参数重复；var 是给局部变量用的，解决整个类型名重复。两者不冲突，但作用域完全不同。
-
<>只出现在new后面，且依赖左侧已有类型声明：List<String> list = new ArrayList<>(); // OK
var list = new ArrayList<>(); // ❌ 编译失败 —— 没有左侧类型，<code><></code> 失效
-
var配合泛型构造器时，要确保右边能提供足够类型线索：var map = new HashMap<String, Integer>(); // OK，泛型已写全
var map = new HashMap(); // 推成 HashMap<Object, Object>，不是你想要的
- JDK 9+ 支持
Map.of()这类静态工厂方法，配合var更安全：var map = Map.of("a", 1, "b", 2); // 推出 Map<String, Integer>
什么时候不该用 var？
类型信息对理解逻辑至关重要时，硬用 var 反而增加阅读成本。
- 返回值类型模糊的 API：
var result = someService.process(data); // process() 返回 Object？泛型？不确定，不如写明类型
- 流式调用链过长，类型层层转换：
var users = repo.findAll().stream().filter(...).map(...).collect(...); // 最终是 List？Set？Collectors.toList() 还是 toMap()？难一眼看出
- 数值字面量容易引发意外类型：
var x = 100; // 推出 int，不是 long 或 short
var y = 100L; // 推出 long
写错后缀可能让后续计算溢出或隐式转换出问题
泛型推断失败的典型错误信息怎么读？
遇到 incompatible types: cannot infer type arguments，说明编译器卡在泛型参数上，不是语法错，而是类型线索不足。
立即学习“Java免费学习笔记（深入）”；
- 常见于自定义泛型方法调用，尤其当参数是 lambda 或方法引用时：
process(() -> "done")→ 编译器不知道这个函数式接口该用哪个泛型参数 - 解法不是加
var，而是显式指定类型参数：process(String::valueOf)
改成this.<String>process(String::valueOf)
- 或者把 lambda 拆成带类型声明的变量再传入，给编译器锚点
- 注意：这种错误在 IDE 里常被掩盖（IDE 用自己推断逻辑），但
javac命令行会明确报出，别只信编辑器提示
类型推断不是魔法，它依赖上下文里的每一个字符。少一个泛型参数、多一个 null、漏掉一个方法重载的限定条件，都可能让推断崩在编译期——而且报错位置往往离真实问题很远。
