@Component vs @Repository 与 @Service：Spring 中三大注解的区别

1. 引言

本文将深入剖析 Spring 框架中三个核心注解：@Component、@Repository 和 @Service 之间的区别。虽然它们看起来功能相似，但在实际开发中合理使用，能提升代码可读性和维护性，也能避免一些“踩坑”。

典型的分层架构中，我们通常会划分出数据访问层（DAO）、服务层（Service）、表现层（Controller）等职责明确的模块。

为了实现 Bean 的自动注册与依赖注入，Spring 提供了基于类路径扫描（classpath scanning）的注解机制。只要加上特定注解，Spring 容器就能自动发现并注册这些类为 Bean，纳入 ApplicationContext 管理。

常见的 stereotype 注解包括：

我们已有文章详细讲解这些注解（如 @Bean 与注解详解），本文聚焦于三者之间的实际差异与使用场景。

核心区别在于：它们是语义化的“角色标签”（stereotype），用于区分不同层级的组件。虽然底层都基于 @Component，但使用更具体的注解能让代码意图更清晰，也便于框架做额外处理。

下面我们逐个分析。

✅ @Component 是最基础的通用注解，可用于任何被 Spring 管理的类。
Spring 的组件扫描（@ComponentScan）默认只识别 @Component 及其“派生注解”。
⚠️ 重点来了：@Service 和 @Repository 本质上都是 @Component 的“特化版本”——它们自己也标注了 @Component！

看源码就明白了：

@Component
public @interface Service {
}

@Component
public @interface Repository {
}

✅ 所以 Spring 能扫描到 @Service 和 @Repository，**不是因为它们本身特殊，而是因为它们自带 @Component**。

💡 小结：@Component 是“根”，其他两个是“子类”。但建议不要在服务或数据层直接用 @Component，而应使用语义更明确的注解。

这个注解不只是“标记”，还有实际功能增强：

✅ 自动翻译持久层异常（Persistence Exception Translation）
Spring 提供 PersistenceExceptionTranslationPostProcessor，能捕获如 SQLException 等底层异常，并转换为 Spring 统一的、非受检异常（unchecked exception），比如 DataAccessException。

这样你在业务代码中就不用写一堆 try-catch(SQLException)，简化异常处理。

要启用该功能，需注册这个后处理器。如果你用的是 Spring Boot，默认已自动配置，无需额外操作。

但如果是传统 Spring 项目，需手动添加：

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

⚠️ 如果你自定义了 DAO 层但没加 @Repository，即使加了 @Component，也不会触发异常翻译！

💡 举个例子：你看到一个类加了 @Service，就知道它可能调用多个 @Repository，处理事务、编排逻辑，而不是直接操作数据库。

注解	层级	特殊功能	推荐使用场景
`@Component`	通用	无	工具类、配置类、或其他非标准分层组件
`@Repository`	数据访问层	✅ 异常自动翻译	DAO、JPA Repository 等持久化类
`@Service`	服务层	❌ 无（仅语义）	业务逻辑封装、事务管理类

✅ 最佳实践建议：

💬 简单粗暴一句话：用对注解，不只是让 Spring 认得你，更是让队友看得懂你。