面向接口编程是将依赖从具体类转向抽象契约，确保替换实现、单元测试和并行开发可行；接口是能力契约而非模板，命名应体现能力，方法签名需稳定，禁止new实现类，依赖须注入接口类型。
面向接口编程不是“先写接口再写实现”这种表面流程，而是把调用方和实现方之间的依赖关系，从具体类（new XxxService()）转向抽象契约（ServiceInterface）——一旦做到这点，替换实现、单元测试、并行开发才真正可行。
接口不是模板，是能力契约
很多人把接口当成“待填空的模板”，但真实场景中，接口定义的是“谁可以做什么”，而不是“你该怎么写”。比如订单系统里 OrderService 接口，核心不是规定必须有 createOrder() 和 cancelOrder()，而是明确告诉调用方：“只要实现了我，你就一定能下单、能取消，参数和返回值语义我已约定好。”
- 接口名建议反映能力，如
PaymentProcessor而非IPaymentService（I前缀无语义，且Java社区已普遍弃用） - 方法签名要稳定：避免频繁增删参数；必要时用
PaymentRequest封装体替代多参，为后续扩展留余地 - 别在接口里塞业务规则注释，那是实现类或文档的事；接口只回答“能干什么”，不解释“为什么这么干”
new 实现类 = 面向接口编程失败的信号
只要你在业务代码里写了 new OrderServiceImpl() 或 new AlipayPaymentProcessor()，就说明你没真正用上接口。真正的面向接口编程，意味着所有依赖都通过构造器/方法参数注入，且变量类型是接口而非实现类。
- 正确姿势：
private final OrderService orderService;（Spring 中由容器注入） - 错误姿势：
OrderService service = new OrderServiceImpl();—— 这和直接写死类名没区别 - 测试时若还靠
new创建对象，说明接口没解耦：应改用Mockito.mock(OrderService.class)或 Spring@MockBean
默认方法不是“偷懒补丁”，是契约演化的安全阀
Java 8 引入 default 方法，不是为了让你少写实现，而是解决“已有接口新增能力却不破坏存量实现”的现实难题。比如给 OrderService 新增 retryAfterFailure()，加 default 后老实现类无需改动就能编译通过。
立即学习“Java免费学习笔记（深入）”；
- 慎用
default做业务逻辑：它属于接口契约一部分，一旦发布就很难删除或修改行为 - 不要在
default方法里调用本接口其他抽象方法（易引发循环调用），更别访问实现类私有状态 - 优先考虑是否该拆新接口（如
RetryableOrderService），而非堆砌默认方法
最容易被忽略的一点：面向接口编程的成败，不取决于你写了几个 interface 文件，而取决于你有没有让所有跨模块、跨团队、跨环境的调用，都只认接口类型、不认实现路径。哪怕只有一处 new 漏网，整个链条的可维护性就打了折扣。
