接口引用是重构的统治性实践，它通过将“能力契约”与“具体实现”分离，实现零侵入替换、测试隔离和模块边界清晰，spring、mybatis、dubbo等主流框架均以此为基石。
接口引用指向实现类对象，不是Java的语法技巧，而是解耦重构真正能落地的支点。它让“谁来干活”和“依赖谁”彻底分开，改实现不碰调用逻辑，加功能不翻旧代码。
为什么说这是重构的“统治性实践”
传统写法中，调用方直接 new 具体类，等于把实现细节焊死在业务逻辑里。比如 new FileLogger() 写在 Service 里，一旦要切到日志服务、加 mock 测试、换存储路径，就得一层层改调用方——重构成本高、风险大、不敢动。
而用接口引用：Logger logger = new CloudLogger();
左边是能力契约（能 log），右边才是具体执行者。Service 只认 Logger 接口，完全不知道背后是文件、网络还是内存。换实现，只动这一行实例化，其余全不动。
它如何支撑真实重构场景
-
替换实现零侵入：从
FileLogger换成CloudLogger或SlackLogger，只需改构造或配置，所有logger.log(...)调用点原封不动 -
测试可快速隔离：单元测试时用
Mockito.mock(Logger.class)替代真实日志组件，避免磁盘 I/O 或网络请求，测试秒级完成 -
模块边界真正清晰：Controller 层持有
UserService接口，不管它底层查 MySQL、走 Redis 还是返回 Mock 数据，各层职责不越界
主流框架都在靠它运转
Spring 的 @Autowired 默认按接口类型注入；MyBatis 的 Mapper 是接口，由框架动态生成代理实现；Dubbo 发布的服务本质就是“接口 + 实现类”分离。它们共同验证一件事：只要系统要长期维护、支持扩展、保障测试质量，就绕不开这个范式。
这不是“推荐用”，而是“必须用”的设计底线
当一个项目开始引入策略模式、工厂模式、插件机制，甚至只是想把数据库操作抽离成独立模块，接口引用就是那个最基础、最不可替代的杠杆。它不增加运行时开销，却大幅降低修改成本——解耦不是目标，是每次重构能顺利推进的前提。
