var用于精简泛型声明，需右侧保留完整泛型参数以保障类型推断准确；变量名应承载业务语义，避免模糊命名；流操作中推荐使用，但方法返回类型不直观或关键约束场景应显式声明。
用 var 精简复杂泛型声明，不是为了删掉类型，而是把注意力从“它是什么类型”转向“它用来做什么”。只要右侧初始化表达式足够明确，编译器就能准确推断，强类型本质毫发无损——字节码和运行时行为与显式声明完全一致。
只在右侧类型清晰且冗长时启用 var
泛型嵌套越深，左侧重复书写越干扰阅读。比如 Map
- ✅ 推荐：var userRolesByDepartment = new HashMap
>(); - ❌ 避免：var cache = new HashMap();（泛型丢失，推断为原始类型，IDE 无法提示，编译器失去检查能力）
关键点：右侧必须保留完整泛型参数——这是编译器推断的唯一依据，也是 IDE 提供准确补全的前提。
用变量名补足语义，代替类型说明
var 不带类型信息，名字就得扛起表达职责。越复杂的泛型，越需要名字直指业务含义。
- ❌ 模糊：var data = new ConcurrentHashMap
>(); （data 是缓存？队列？临时结果？） - ✅ 清晰：var pendingNotificationsByUserId = new ConcurrentHashMap
>(); （线程安全 + 业务实体 + 键值含义全到位）
小技巧：名字中可自然融入泛型关键特征，如 ByUserId、WithRetry、ForExport，比注释更可靠、更不易过时。
流操作与链式调用中优先使用 var
一串 .stream().filter().map().collect() 后，目标类型往往由 Collectors 明确决定，显式写全类型反而打断逻辑流。
- ✅ 自然流畅：var activeUsersById = users.stream().filter(User::isActive).collect(Collectors.toMap(User::getId, Function.identity()));
- ✅ IDE 悬停即见 Map
，无需中断阅读去确认类型 - ❌ 避免：var result = service.fetchData();（方法返回类型不直观，推断结果对读者完全不可见）
警惕“省类型”换来的隐性代价
有些泛型看似啰嗦，实则承载关键约束。盲目用 var 可能掩盖设计意图，甚至埋下运行时隐患。
- ❌ 危险：var numbers = Arrays.asList(1, 2, 3); → 推断为 List
，但后续若需 add(null) 或混入 Long，问题延后暴露 - ✅ 更稳：List
numbers = Arrays. （显式上界，约束更准）asList(1, 2L, 3.14); - ❌ try-with-resources 中勿省略资源类型：var fis = new FileInputStream("x.txt"); → 资源关闭行为依赖具体类，类型模糊削弱静态检查
