接口是依赖注入落地的关键抽象载体，它定义契约、隔离实现、支撑自动装配与测试替身，并与di协同实现松耦合、可替换和可演进的工程实践。
接口是依赖注入得以落地的关键抽象载体，没有接口（或抽象类），DI就容易退化为对具体实现的硬绑定，失去松耦合的核心价值。
接口为DI提供契约基础
依赖注入不是把任意对象塞进另一个对象，而是按约定交付——这个约定就是接口。它定义了“能做什么”，不关心“谁来做”。比如一个PaymentService接口声明process()方法，订单服务只需依赖该接口，而不必知道背后是支付宝、微信还是模拟支付实现。
- 接口隔离了使用方与实现方，使注入行为有据可依
- 容器根据接口类型匹配并注入对应实现类，这是自动装配的前提
- 单元测试时可轻松注入MockPaymentService等测试替身，无需修改业务代码
DI强化接口的实际价值
光有接口不够，若仍由业务类自行new实现类，接口就形同虚设。DI通过外部容器接管实例创建，强制依赖必须通过接口注入，从而真正落实“面向接口编程”。
- 构造函数参数声明接口类型，迫使调用方提供符合契约的实现
- Setter或字段注入也需标注接口类型（如@Autowired private PaymentService paymentService;）
- Spring等框架在启动时校验接口是否有且仅有一个候选Bean，避免歧义
接口+DI共同支撑可替换性
系统演进中常需切换底层实现（如从本地缓存换成Redis），只要新实现类实现同一接口，并在容器中重新注册，所有依赖该接口的组件无需改动即可生效。
- 无需修改订单、用户等上层服务代码
- 配置层面切换（如@Profile("prod")指定不同实现）
- 灰度发布时可按条件注入不同实现，实现运行时策略切换
接口定义能力边界，DI负责按需交付能力——二者配合，才让“解耦”不是口号，而是可执行、可验证、可演进的工程实践。
