官網引用
引用spring的官方文檔中的一段描述：
在Spring2.0之前的版本中，@Repository注解可以標記在任何的類上，用來表明該類是用來執行與數據庫相關的操作（即dao對象），並支持自動處理數據庫操作產生的異常
在Spring2.5版本中，引入了更多的Spring類注解：@Component,@Service,@Controller。@Component是一個通用的Spring容器管理的單例bean組件。而@Repository, @Service, @Controller就是針對不同的使用場景所采取的特定功能化的注解組件。
因此，當你的一個類被@Component所注解，那么就意味着同樣可以用@Repository, @Service, @Controller來替代它，同時這些注解會具備有更多的功能，而且功能各異。
最后，如果你不知道要在項目的業務層采用@Service還是@Component注解。那么，@Service是一個更好的選擇。
就如上文所說的，@Repository早已被支持了在你的持久層作為一個標記可以去自動處理數據庫操作產生的異常（譯者注：因為原生的java操作數據庫所產生的異常只定義了幾種，但是產生數據庫異常的原因卻有很多種，這樣對於數據庫操作的報錯排查造成了一定的影響；而Spring拓展了原生的持久層異常，針對不同的產生原因有了更多的異常進行描述。所以，在注解了@Repository的類上如果數據庫操作中拋出了異常，就能對其進行處理，轉而拋出的是翻譯后的spring專屬數據庫異常，方便我們對異常進行排查處理）。
| 注解 | 含義 |
|---|---|
| @Component | 最普通的組件，可以被注入到spring容器進行管理 |
| @Repository | 作用於持久層 |
| @Service | 作用於業務邏輯層 |
| @Controller | 作用於表現層（spring-mvc的注解） |
其他網上資料
這幾個注解幾乎可以說是一樣的：因為被這些注解修飾的類就會被Spring掃描到並注入到Spring的bean容器中。
這里，有兩個注解是不能被其他注解所互換的：
@Controller 注解的bean會被spring-mvc框架所使用。 @Repository 會被作為持久層操作（數據庫）的bean來使用
如果想使用自定義的組件注解，那么只要在你定義的新注解中加上@Component即可：
-
-
-
public
這樣，所有被@ScheduleJob注解的類就都可以注入到spring容器來進行管理。我們所需要做的，就是寫一些新的代碼來處理這個自定義注解（譯者注：可以用反射的方法），進而執行我們想要執行的工作。
@Component就是跟<bean>一樣，可以托管到Spring容器進行管理。
@Service, @Controller , @Repository = {@Component + 一些特定的功能}。這個就意味着這些注解在部分功能上是一樣的。
當然，下面三個注解被用於為我們的應用進行分層：
@Controller注解類進行前端請求的處理，轉發，重定向。包括調用Service層的方法 @Service注解類處理業務邏輯 @Repository注解類作為DAO對象（數據訪問對象，Data Access Objects），這些類可以直接對數據庫進行操作
有這些分層操作的話，代碼之間就實現了松耦合，代碼之間的調用也清晰明朗，便於項目的管理；假想一下，如果只用@Controller注解，那么所有的請求轉發，業務處理，數據庫操作代碼都糅合在一個地方，那這樣的代碼該有多難拓展和維護。
總結
@Component, @Service, @Controller, @Repository是spring注解，注解后可以被spring框架所掃描並注入到spring容器來進行管理 @Component是通用注解，其他三個注解是這個注解的拓展，並且具有了特定的功能 @Repository注解在持久層中，具有將數據庫操作拋出的原生異常翻譯轉化為spring的持久層異常的功能。 @Controller層是spring-mvc的注解，具有將請求進行轉發，重定向的功能。 @Service層是業務邏輯層注解，這個注解只是標注該類處於業務邏輯層。
用這些注解對應用進行分層之后，就能將請求處理，義務邏輯處理，數據庫操作處理分離出來，為代碼解耦，也方便了以后項目的維護和開發。