接口引用是Java解耦的底层核心，通过分离“依赖谁”与“谁来干活”，实现替换实现零侵入、单元测试可落地、模块边界清晰；Spring等主流框架均基于此范式构建。
接口引用指向实现类对象，是Java解耦框架的底层支点。它不是语法糖，而是把“依赖谁”和“谁来干活”彻底分开的设计选择。
为什么说这是解耦的统治性实践
传统写法中，调用方直接 new 一个具体类，等于把实现细节钉死在代码里。一旦要换逻辑、加日志、切测试桩，就得改调用方——牵一发而动全身。而用接口引用，比如：
Logger logger = new FileLogger();
左边声明的是能力（能log），右边才是干活的人（FileLogger）。调用方只认 Logger 这个契约，根本不知道背后是文件、控制台还是网络服务。
它如何支撑真实开发场景
- 替换实现零侵入：从 new FileLogger() 换成 new CloudLogger()，只需改一行实例化代码，所有调用 logger.log() 的地方完全不用动
- 单元测试可落地：用 Mockito.mock(Logger.class) 替代真实实现，避免启动数据库或调用外部 API，测试快且稳定
- 模块边界清晰：Controller 层只依赖 UserService 接口，不关心它是查 MySQL、Redis 还是 Mock 数据，各层真正各司其职
这不是“能用”，而是“必须用”的底层逻辑
Spring、MyBatis、Dubbo 等主流框架全部基于这套机制构建。Spring 的 @Autowired 默认按类型注入，找的就是接口的某个实现；MyBatis 的 Mapper 接口由框架动态代理生成实现；Dubbo 暴露的服务本质也是接口 + 实现类分离。它们共同验证了一点：只要系统需要扩展、测试、维护，就绕不开接口引用这个范式。
容易忽略的关键细节
-
接口不能被 new，但可以被声明：你写 List
list = new ArrayList(); ，左侧是契约，右侧是执行者——这和 Logger 示例是同一套逻辑 - 多态绑定发生在运行时：JVM 看的是实际对象类型，不是变量声明类型。哪怕你写 Shape s = new Circle();，调用 s.draw() 执行的永远是 Circle 的 draw 方法
- 一个类实现多个接口，就是多个角色自由组合：比如 PaymentService 同时实现 Payable 和 Refundable，不同上下文只看到它需要扮演的那一面
