这里给出的答案在技术上是部分正确的，但即使答案列表很长，这将是底部，我认为在这里也应该给出一个真正正确的答案，以防有人偶然发现并从中学习到有价值的东西。这并不是说其余的答案完全错误，只是它们不正确。而且，为了阻止成群的巨魔，是的，我知道，从技术上讲，这些注释现在实际上是一样的，甚至到第5春，它们都可以互换。现在，对于正确的答案：

这三种注释是完全不同的，不可互换。你可以这么说，因为他们有三个而不是一个。它们并不是可互换的，它们只是出于优雅和方便而实现的。

现代编程是不同比例的发明、艺术、技术和通信。通信位通常非常重要，因为代码的读取频率通常比编写频率高得多。作为一名程序员，你不仅试图解决技术问题，还试图将你的意图传达给阅读你代码的未来程序员。这些程序员可能既不共享您的母语，也不共享您所处的社交环境，而且他们可能在未来50年内阅读您的代码（这并不像您想象的那样不可能）。在未来很难有效地沟通。因此，我们必须使用最清晰、最有效、最正确、最具交际能力的语言。我们谨慎地选择词汇，以产生最大的影响，并尽可能清楚地表达我们的意图。

例如，在编写存储库时使用@Repository而不是@Component是非常重要的。后者对于存储库来说是一个非常糟糕的注释选择，因为它并不表示我们正在查看存储库。我们可以假设存储库也是一个springbean，但不能假设组件是一个存储库。有了@Repository，我们的语言变得清晰而具体。我们明确表示，这是一个存储库。有了@Component，我们就让读者来决定他们阅读的是什么类型的组件，他们必须阅读整个类（以及可能的子类和接口树）来推断含义。在遥远的将来，该类可能会被读者误解为不是一个存储库，我们可能会对这个错误承担部分责任，因为我们深知这是一个存储，但未能在我们的语言中明确表达我们的意图。

我将不讨论其他示例，但将尽可能清楚地说明：这些注释是完全不同的东西，应根据其意图适当使用@存储库用于存储存储库，其他注释都不正确@服务用于服务，其他注释不正确@控制器适用于既不是存储库也不是服务的组件，在其位置使用其中任何一个都是不正确的。它可能会编译，甚至可能运行并通过您的测试，但这是错误的，如果您这样做的话，我会对您（专业）的评价降低。

整个春季都有这样的例子（以及一般的编程）。编写REST API时不能使用@Controller，因为@RestController可用。当@GetMapping是有效的替代方案时，不能使用@RequestMapping。你必须选择最具体、最准确、最正确的语言来向读者传达你的意图，否则，你会给你的系统带来风险，风险是有代价的。

最后，我想提出一个关于面向对象系统的问题。基本规则之一是，实现可以变化，但接口不应该变化。假设这些注释是相同的，这是一个非常棘手的问题，完全违背OO。尽管它们现在可能以可互换的方式实现，但不能保证将来会实现。此外，即使在同一个团队中，工程师也可能会决定使用方面暂停这些注释中的一个或多个，或者平台工程师可能会出于操作原因选择替换其中一个的实现。你只是不知道，也不应该知道——在OO中，你依赖的是接口，而不是实现。

从数据库连接的角度来看，使用@Service和@Repository注释很重要。

对所有web服务类型的DB连接使用@Service将@Repository用于所有存储过程数据库连接

如果没有使用正确的注释，则可能会遇到回滚事务覆盖的提交异常。您将在压力负载测试期间看到与回滚JDBC事务相关的异常。

Spring2.5引入了更多的原型注释：@Component、@Service和@Controller@组件充当任何Spring管理组件的通用原型；而@Repository、@Service和@Controller作为@Component的特殊化，用于更具体的用例（例如，分别在持久性、服务和表示层）。这意味着你可以用@component来注释你的组件类，但是通过用@Repository、@Service或@Controller来注释它们，你的类更适合由工具处理或与方面关联。例如，这些原型注释是切入点的理想目标。当然，@Repository、@Service和@Controller也有可能在未来的Spring Framework版本中携带额外的语义。因此，如果您在服务层使用@Component或@Service之间做出决定，@Service显然是更好的选择。类似地，如上所述，@Repository已经被支持作为持久层中自动异常转换的标记。@组件–表示自动扫描组件。@Repository–表示持久层中的DAO组件。@服务–表示业务层中的服务组件。@控制器–表示表示层中的控制器组件。

参考：-Spring Documentation-Classpath扫描、托管组件和使用Java编写配置

在Spring@Component中，@Service、@Controller和@Repository是Stereotype注释，用于：

@Controller：在完成了来自演示页面的请求映射的地方，即演示层不会转到任何其他文件，它会直接转到@Controller类，并在@RequestMapping注释中检查请求的路径，如果需要，该注释在方法调用之前编写。

@服务：所有业务逻辑都在这里，即与数据相关的计算和所有。此业务层注释中，我们的用户不直接调用持久性方法，因此将使用此注释调用此方法。它将根据用户请求请求@Repository

@存储库：这是用于从数据库获取数据的应用程序的持久层（数据访问层）。即，所有与数据库相关的操作都由存储库完成。

@组件-使用组件原型注释其他组件（例如REST资源类）。

指示带注释的类是“组件”。此类类为使用时被视为自动检测的候选项基于注释的配置和类路径扫描。其他类级别注释可被视为标识组件，通常是一种特殊类型的组件：例如@Repository注解或AspectJ的@Aspect注解。

这里有足够好的答案来解释组件存储库服务注释之间的区别。我想分享@Controller和@RestController之间的区别

@控制器与RestController

@RestController（RestController）：

此注释是@Controller的专用版本，它添加了@Controller和@ResponseBody自动注释。因此我们不必将@ResponseBody添加到映射方法中。这意味着@ResponseBody默认处于活动状态。如果使用@RestController，则无法返回视图（通过使用Spring/Spring Boot中的Viewresolver）@RestController还将响应自动转换为JSON/XML，因为@ResponseBody将返回的对象转换为可能在主体中的对象，例如JSON或XML

---

@控制器

@控制器用于将类标记为SpringMVC控制器。这注释只是@Component的一个专门版本允许基于类路径自动检测控制器类扫描。@控制器，您可以在SpringwebMVC中返回视图。

更详细的视图

由于许多答案已经说明了这些注释的用途，我们将在这里重点讨论它们之间的一些细微差异。

首先是相似性值得再次强调的第一点是，关于扫描自动检测和BeanDefinition的依赖注入，@Repository、@Controller）是相同的。我们可以就地使用另一个的，仍然可以得到我们的方式。

---

@Component、@Repository、@Controller和@Service之间的差异

@组件

这是一个通用的原型注释，表明该类是一个弹簧组件。

@Component有什么特别之处<context:componentscan>仅扫描@component，通常不查找@Controller、@Service和@Repository。它们被扫描，因为它们本身带有@Component注释。

只需查看@Controller、@Service和@Repository注释定义即可：

@Component
public @interface Service {
    ….
}

 

@Component
public @interface Repository {
    ….
}

 

@Component
public @interface Controller {
    …
}

因此，@Controller、@Service和@Repository是@Component注释的特殊类型并不是错误的<context:componentscan>拾取它们并将它们的以下类注册为bean，就像它们用@component注释一样。

特殊类型注释也会被扫描，因为它们本身是用@Component注释注释的，这意味着它们也是@Components。如果我们定义自己的自定义注释并使用@Component对其进行注释，那么它也将通过<context:componentscan>进行扫描

---

@存储库

这表示该类定义了一个数据存储库。

@Repository有什么特别之处？

除了指出这是一个基于注释的配置之外，@Repository的工作是捕获特定于平台的异常，并将其作为Spring的统一未检查异常之一重新抛出。为此，我们提供了PersistenceExceptionTranslationPostProcessor，需要将其添加到Spring的应用程序上下文中，如下所示：

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

这个bean后处理器向用@Repository注释的任何bean添加一个advisor，以便捕获任何特定于平台的异常，然后作为Spring未检查的数据访问异常之一重新抛出。

---

@控制器

@Controller注释表示特定类充当控制器的角色。@Controller注释充当注释类的原型，指示其角色。

@Controller有什么特别之处？

我们无法将此注释与任何其他注释（如@Service或@Repository）切换，即使它们看起来相同。分派器扫描用@Controller注释的类，并检测其中用@RequestMapping注释注释的方法。我们只能在类用@Controller注释的方法上/中使用@RequestMapping，它不能与@Component、@Service、@Repository等一起使用。。。

注意：如果一个类已经通过任何替代方法注册为bean，例如通过@bean或通过@Component、@Service等注释，那么如果该类也使用@RequestMapping注释进行注释，则可以选择@RequestMapping。但情况不同。

---

@服务

@服务bean在存储库层中保存业务逻辑和调用方法。

@Service有什么特别之处？

除了它用来表示，它持有业务逻辑之外，这个注释中没有其他值得注意的地方；但谁知道呢，Spring可能会在未来增加一些额外的例外。

---

还有什么？

与上述类似，未来Spring可能会根据其分层约定为@Service、@Controller和@Repository添加特殊功能。因此，尊重惯例并按照层使用它总是一个好主意。