【MyBatis Plus】@Service标签应该放在ServiceImpl上(接口不可以实例化)

@Component及其衍生注解（@Service/@Controller/@Repository）都不应该标注在接口上！@Service注解要标注在ServiceImpl（实现类）上而非Service（接口）上，核心原因是Spring 容器只能实例化 “具体类”，无法实例化接口，且这是 Spring 依赖注入（DI）和面向接口编程的核心设计逻辑，我从「底层原理、实战意义、避坑点」三个维度讲透：

一、核心原理：Spring 容器的 “实例化规则”

1. 接口无法被实例化：Service接口（如UserService）只是方法定义，没有具体实现，JVM 本身就无法创建接口的对象；@Service的本质是告诉 Spring：“把这个类实例化成 Bean，放到容器中”—— 接口连对象都创建不了，标注@Service毫无意义。

2. 实现类是 “可实例化的具体类”：ServiceImpl（如UserServiceImpl）是接口的具体实现，包含方法的完整逻辑，Spring 能通过反射创建它的实例，并将实例注册到 IoC 容器中。

   举个反例（错误写法）：

   // ❌ 错误：接口加@Service，Spring无法实例化 @Service public interface UserService { boolean login(String username, String password); } // ✅ 正确：实现类加@Service，Spring能创建实例 public class UserServiceImpl implements UserService { @Override public boolean login(String username, String password) { // 业务逻辑 return true; } }

   这种写法启动时会报错：No qualifying bean of type 'UserService' available（找不到 UserService 类型的 Bean）。

二、实战意义：面向接口编程 + 依赖注入

Spring 推荐 “面向接口编程”，核心流程是：

1. 定义接口：UserService定义业务方法（规范）；
2. 实现类加 @Service：UserServiceImpl实现接口，加@Service让 Spring 实例化；
3. 控制器注入接口：

   java

   运行

   @RestController public class LoginController { // 注入接口（而非实现类），解耦 @Autowired private UserService userService; }

   • Spring 会自动找到UserService接口的实现类（UserServiceImpl），把容器中的实例注入到控制器；
   • 如果后续替换实现类（如UserServiceV2Impl），只需修改实现类的@Service，控制器代码无需改动（解耦核心）。

三、补充：为什么不能给接口加 @Service？

除了 “无法实例化”，还有两个关键问题：

1. 多实现类冲突：如果一个接口有多个实现类（如UserServiceImpl、AdminUserServiceImpl），若给接口加@Service，Spring 无法判断该实例化哪个实现类，会报NoUniqueBeanDefinitionException；
2. 违背设计原则：接口是 “契约”，标注@Service这种 “容器相关注解” 会污染接口，接口应只关注业务方法定义，和容器解耦。