SpringBoot应用中每个@Service类都需要实现对应接口吗

这种做法流行的核心原因 #

• 历史遗留习惯：Spring早期版本AOP默认使用JDK动态代理，必须依赖接口才能实现切面逻辑（比如事务、日志切面），当时强制要求Service层写接口是硬性需求。这个规范被很多老开发者、老项目延续至今，哪怕Spring Boot 2.x之后已经默认使用CGLib动态代理，无接口也能正常实现AOP能力，这个习惯还是被保留了下来。
• 过度设计的惯性：很多团队照搬经典软件工程的「面向接口编程」原则，没有结合实际业务场景判断，默认把「接口+实现」的模式当成唯一标准，忽略了该模式的前提是存在多实现、需要契约隔离的场景。

很多项目中常见的无意义接口写法如下：

public interface MyService {} 
@Service
public class MyServiceImpl implements MyService {}

该做法的实际收益（仅在匹配场景下成立） #

如果你的业务确实符合以下场景，为Service编写接口是有明确价值的：

• 同一业务逻辑存在多个实现类，比如通知服务有短信通知、邮件通知、站内信通知多个实现，上层调用方只依赖接口，不需要关心具体实现逻辑
• 需要做模块隔离，比如核心业务层和外部依赖层需要解耦，避免上层直接依赖底层实现细节
• 部分老旧的测试框架需要依赖接口才能生成Mock对象，不过当前主流测试框架（Mockito等）已经支持直接Mock实现类，这个优势基本已经消失

实际开发建议 #

99.99%无多实现的业务Service场景下，强制编写对应接口不属于Spring Boot官方推荐的最佳实践，反而会带来额外的维护成本：修改业务方法需要同时改接口和实现类两层，增加代码冗余，查找逻辑的时候还要多跳一层。
实际开发中可以按需选择，不需要一刀切：

• 普通业务Service，只有一个实现且未来无扩展计划的，直接写@Service标注的实现类即可，不需要额外加接口
• 确实有多个实现、契约隔离需求的Service，再补充对应的接口即可

内容的提问来源于stack exchange，提问作者Emmanuel Piard