面向接口编程的本质是“换实现不改调用方”，即通过声明接口类型（如List、UserService）而非具体实现类，使底层实现可替换而不影响调用方代码，适用于多实现或需模拟/隔离测试的场景，避免硬编码实现导致的耦合与维护风险。

面向接口编程的本质是“换实现不改调用方”

这不是为了显得高级，而是为了解决一个非常实际的问题：当你写 new ArrayList()，后续想换成 LinkedList 或带缓存的自定义列表时，所有用到它的位置都得手动改——这在中大型项目里等于埋雷。而如果变量声明为 List，底层怎么换，调用方完全不用动。

• 接口定义的是「能做什么」，不是「怎么做」或「怎么配」；比如 PaymentService 该有 process(

  

  )，但不该有 setRetryTimes()
• Spring 的 @Autowired 默认按类型注入，所以 @Autowired private UserService userService; 才能成功找到 UserServiceImpl；写成 @Autowired private UserServiceImpl 就锁死了实现，多实现时直接失败
• 测试时可轻松用 Mockito.mock(UserService.class) 替代真实服务，不用动业务逻辑代码

哪些地方真该抽接口？哪些硬加反而坏事？

接口不是万能胶，也不是越多越好。它只在两类场景下真正必要：

• 可能有多种实现：比如 OrderRepository（JDBC / Redis / Mock）、SmsClient（阿里云 / 腾讯云 / 本地模拟）、PricingStrategy（满减 / 折扣 / 积分抵扣）
• 需要被模拟或替换：尤其是涉及外部依赖（HTTP、DB、文件系统）或需隔离测试的模块
• 反例：工具类如 StringUtils、DTO 对象、或确定永远只有一个实现的 LocalDateTimeUtils，加接口只会增加跳转成本，没人 mock 它，就该删掉

Spring 里最常踩的坑：@Autowired 写错类型

很多人以为写 @Autowired private UserServiceImpl userService; 更“直白”，结果导致两个问题：

• 当新增 AuditingUserService 实现同一接口时，Spring 找不到唯一 Bean，抛 NoUniqueBeanDefinitionException
• 后续想切实现（比如灰度用新服务），必须改所有注入点，违背开闭原则
• 正确做法是只依赖接口，并用 @Primary 或 @Qualifier("auditingUserService") 明确指定实现

接口方法设计最容易忽略的边界

一个接口方法是否该放进接口，关键看它是不是所有实现都「必须支持」且「语义一致」：

• 别把配置类方法塞进接口，比如 enableDebugMode() 或 setBatchSize(int) —— 这些是实现细节，暴露出去会污染契约
• 默认方法（default）慎用：除非是领域共识逻辑，比如 Collection.isEmpty()；否则就是变相把实现逻辑强加给所有实现类
• 接口名用名词或动名词，如 OrderValidator、LoggingAspect；别用 DoSomethingInterface 这种后缀，那是信号：你已经不知道这个接口到底要表达什么了

真正难的从来不是“能不能抽接口”，而是判断“值不值得抽”——当一个接口长期只有 1 个实现、从没被 mock 过、也没人讨论要不要换实现，那它大概率只是个摆设。