var不参与接口规约，仅编译期推断类型；保障强类型的关键是右侧表达式必须明确返回已实现目标接口的具体类型，如构造器调用、工厂方法或显式转型等。
var 本身不参与接口规约，它只是编译期对局部变量类型的自动推断工具。要保障强类型规约，关键不在 var 怎么写，而在于你用 var 声明的变量，其右侧初始化表达式是否明确返回了符合接口契约的具体类型。
var 的作用边界：它不定义契约，只复用已有契约
Java 中的接口（如 Runnable、Function<String, Integer> 或自定义接口 DataProcessor）定义的是行为契约和类型约束。var 不会改变这个契约，也不会“实现”或“继承”接口——它只是让编译器从右侧表达式中提取出一个**已实现该接口的具体类型**，并用更简洁的方式声明变量。
例如：
✅ 正确用法（契约清晰）：
-
var processor = new JsonDataProcessor();→ 推断为JsonDataProcessor类型，该类显式implements DataProcessor，所以变量天然满足DataProcessor规约 -
var handler = (Consumer<String>) System.out::println;→ 显式转型确保类型为Consumer<String>，var 仅简化左侧书写 -
var service = ServiceFactory.createOrderService();→ 若createOrderService()返回OrderService（实现了OrderServiceInterface），则 var 变量仍具备完整接口能力
必须确保右侧表达式携带明确的接口语义
var 能“保障”强类型规约的前提，是初始化值本身已绑定到具体接口实现。编译器不会凭空赋予接口能力，它只忠实地还原右侧表达式的静态类型。
常见可靠来源包括：
-
构造器调用：类明确实现接口（如
new FileLogger() implements Logger） -
工厂方法返回值：方法签名声明返回接口类型（如
Logger createLogger()） -
显式转型或方法引用：如
(Runnable) () -> {}或String::length（对应ToIntFunction<String>） - Lambda 表达式 + 函数式接口上下文：在赋值给接口变量或传参时类型已知，再用 var 声明中间变量才安全
容易破坏规约的典型误用
以下写法看似用了 var，实则丢失接口抽象性，削弱类型规约效果：
-
var logger = LoggerFactory.getLogger(MyClass.class);→ 返回Logger（通常为 SLF4J 的Logger接口），没问题；但若该方法返回Object或泛型擦除严重（如getBean("xxx")），则推断可能为Object，失去接口能力 -
var result = someService.process(data);→ 若process()返回Object或未声明泛型，var 将推断为最宽泛类型，无法调用DataProcessor特有方法 -
var impl = new CustomImpl();→ 如果CustomImpl没有实现目标接口，即使你心里想让它“充当”该接口，var 也无法强制规约；运行时调用接口方法会编译失败
配合 IDE 和静态检查强化规约意识
现代 IDE（IntelliJ、Eclipse）在使用 var 时能实时显示推断类型。把鼠标悬停在 var 上，确认它确实是你要的接口实现类，而非父类或 Object。
建议搭配以下实践：
- 在接口定义处加 Javadoc 明确契约意图，让 var 变量的用途一目了然
- 对关键服务变量，初期可先显式写一次接口类型（如
DataProcessor processor = ...），验证逻辑无误后再改为var processor = ...，确保右侧没“掉链子” - 启用编译器参数
-Xlint:varargs或使用 SpotBugs 等工具，识别隐式类型丢失风险
