原文来自于：zha-ge.cn/java/116
你以为只是名字不同？Spring 三大注解的真正差别曝光
说实话，刚入坑 Spring 的时候，我也觉得 @Component、@Service、@Repository 就是换了个名字，反正都能把类丢进容器里，有啥区别？
结果第一次面试被问到"这三个注解有什么本质不同？"我支支吾吾："呃......名字不一样？"
面试官沉默了一下，轻轻地在简历上画了一笔。
后来踩了无数坑，我才明白：这些注解，虽然"看起来都能扫进容器"，但背后的语义和用途，可一点都不一样。
那些年，我以为它们是一样的
早期写项目的时候，我的习惯是这样的：
kotlin
@Component
public class UserService { ... }能用就行，反正 Spring 会自动扫描包名、实例化、注册 Bean，没毛病啊。
于是项目里，Controller、Service、DAO，全都是 @Component，整整齐齐。
直到有一天，日志里出现了数据库异常，却没有被转换成 Spring 的 DataAccessException，我才后知后觉：原来 @Repository 根本不只是换个壳子。
Spring 三大注解的定位与语义
Spring 官方的推荐用法，其实非常讲"分层语义"：
- @Component：通用组件注解，所有 Bean 的"老祖宗"，没有特定语义，Spring 只负责把它注册到容器中。
- @Service：语义化更强，标识业务逻辑层的组件，强调这是"服务"而不是纯工具。
- @Repository：专为数据访问层设计，除了注册 Bean，还带着"异常转换"的副作用。
换句话说：
👉 @Component 是最原始的"收录器"
👉 @Service 是告诉别人"这里是业务逻辑"
👉 @Repository 是数据库层的"异常翻译官"
异常转换：@Repository 的隐藏技能
@Repository 最大的不同点就在于它不只是"注册个 Bean"而已，它还会对底层持久化异常进行捕获和转换 ，把原始的 JDBC 或 JPA 异常转换成 Spring 统一的 DataAccessException 层次结构。
举个例子👇：
typescript
@Repository
public class UserDao {
public void save(User user) {
// 如果抛出 SQLException
}
}如果这里抛出的是原生的 SQLException，Spring 会在底层 AOP 切面中自动捕获并转换成一个 DataAccessException，这样上层代码就不用关心底层数据库是 MySQL、Oracle 还是 PostgreSQL 了。
你用 @Component 写这个类？对不起，异常不会自动转换，你得自己手动处理。
@Service 的语义价值：不仅仅是"语法糖"
再说说 @Service。
它在功能上确实和 @Component 一致，但语义层次更清晰 ------ 当你在一个几百个 Bean 的大项目里找 bug 时，一眼看到 @Service 就知道这是业务逻辑层，不用猜它的职责。
在分布式系统中，这个语义还可以和 AOP 切面结合，对所有 @Service Bean 做统一处理，比如性能监控、日志埋点、鉴权等。
例如：
java
@Around("@within(org.springframework.stereotype.Service)")
public Object logServiceCalls(ProceedingJoinPoint pjp) throws Throwable {
// 只对业务层方法打点
}如果你用的是 @Component，这个切面就匹配不到了。
真·踩坑现场：语义乱用导致维护地狱
我曾经接手过一个老项目，全项目只有两个注解：@Controller 和 @Component。
业务逻辑和 DAO 全是 @Component，日志埋点用注解扫描也失效，AOP 切面拦不住，异常也不再统一。
重构完换上 @Service 和 @Repository 之后，日志统计、事务传播和异常翻译全都顺畅了。
所以别小看"名字"的作用 ------ 这不仅是语义标签，也是框架行为触发的开关。
经验启示
踩过坑的我，总结了三条硬核建议：
- @Component 万金油，但少用为妙：通用组件可以用它，但该分层就要分层。
- @Service 是业务层的标识：不仅语义清晰，还能和 AOP 配合做切面拦截。
- @Repository 是 DAO 层的最佳选择：自动异常转换、和持久化框架集成更自然。
一句话记住：语义 ≠ 装饰，语义 = 功能。
收个尾巴
"你以为只是名字不同"这句话，说的是我刚入门时的天真。
在 Spring 的世界里，@Component、@Service、@Repository 虽然都能注册 Bean，但语义、行为、副作用却大不相同。
从容器扫描到异常翻译，从层级划分到 AOP 切面，它们早已超越"换个壳"的层面，是整个分层架构协作的基础。
所以，别再图省事一律 @Component。
当你写出一个职责分明、行为明确、切面精准的 Spring 应用时，你就会发现：名字不同，意义大了去了。
要不要我下一篇写《@Configuration 和 @Bean 的底层区别与最佳实践》，它和这篇一样，是面试高频"表面一样但底层差很远"的注解对比题。