面向接口编程的本质是“换实现不改调用方”，即通过声明接口类型（如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")明确指定实现
接口方法设计最容易忽略的边界
一个接口方法是否该放进接口，关键看它是不是所有实现都「必须支持」且「语义一致」：
立即学习“Java免费学习笔记（深入）”；
- 别把配置类方法塞进接口，比如
enableDebugMode()或setBatchSize(int)—— 这些是实现细节，暴露出去会污染契约 - 默认方法（
default）慎用：除非是领域共识逻辑，比如Collection.isEmpty()；否则就是变相把实现逻辑强加给所有实现类 - 接口名用名词或动名词，如
OrderValidator、LoggingAspect；别用DoSomethingInterface这种后缀，那是信号：你已经不知道这个接口到底要表达什么了
真正难的从来不是“能不能抽接口”，而是判断“值不值得抽”——当一个接口长期只有 1 个实现、从没被 mock 过、也没人讨论要不要换实现，那它大概率只是个摆设。
