互换@Service、@Controller、@Repository等Spring注解会产生什么影响？

首先需要明确，这三个注解本质上都是 @Component 的派生注解，Spring 启动扫描 Bean 时，所有标记了 @Component 及其派生注解的类都会被实例化纳入容器管理，所以如果你的项目没有用到和这三个注解绑定的特殊特性，只是简单的业务逻辑实现，互换注解大概率不会直接导致功能报错，这也是很多开发者觉得“乱标也没事”的原因。

但在用到注解关联的内置特性、或者项目有自定义切面逻辑的场景下，互换注解会直接触发问题，常见的影响如下：

• @Repository 特有特性失效：Spring 会为所有标记了 @Repository 的持久层类自动添加异常转译切面，会把 JDBC、JPA 等持久化操作抛出的平台相关 checked 异常（比如 SQLException），转换成 Spring 统一的 DataAccessException 非受检异常体系，方便上层统一做异常处理。如果将 @Service 或 @Controller 标注在 DAO 层类上，这个自动异常转译能力会直接失效，你需要手动处理各类底层持久化异常，会大幅提升代码耦合度和上层异常处理的复杂度。
• @Controller 特有特性失效：只有标记了 @Controller（包括其派生的 @RestController）的类，Spring MVC 才会识别其中的 @GetMapping、@PostMapping、@RequestMapping 等路由注解，将对应方法绑定为可访问的 HTTP 接口。如果将 @Service 或 @Repository 标注在原本的 Controller 类上，Spring 不会将其识别为 Web 控制器，类中定义的所有接口都会直接返回 404，完全无法访问。
• 自定义 AOP 逻辑失效：绝大多数企业级项目都会基于注解做通用切面逻辑，比如给所有 @Service 类添加方法执行耗时统计、给所有 @Controller 类做请求参数日志打印、接口响应统一包装、权限校验等。如果注解乱标，这些预设的 AOP 逻辑就无法匹配到目标类，该打的日志打不出来，该做的权限校验不生效，很容易引发线上故障。
• 代码可维护性大幅下降：就算上述特性你都没有用到，乱标注解也会破坏 Spring 项目约定俗成的分层规范，其他开发人员接手代码时，默认会通过注解判断类的分层职责，乱标会大幅提升代码理解成本，后续排查问题、迭代功能的效率都会明显降低。

内容的提问来源于stack exchange，提问作者Saniya Javed