刚入行做SSM整合开发的时候，最头疼的就是分不清各类注解的用法，对着网上杂乱的资料翻来翻去，始终搞不懂springmvc注解有哪些、哪些是项目刚需、哪些基本用不上，实操的时候经常漏写、错写注解，导致接口访问404、参数接收失败、页面跳转异常一堆问题。那段时间几乎天天卡在注解配置上，反复调试代码、对照源码测试，慢慢摸透了日常开发里真正能用得上的所有SpringMVC注解，都是实打实跑过项目、踩过坑总结出来的实操内容。
最先频繁用到的就是控制器核心注解，也是SpringMVC项目的基础骨架。@Controller是最基础的，专门用来标识当前类是控制器层，交给Spring容器管理，没有这个注解，整个类的接口都会失效，浏览器完全映射不到请求地址。最开始偷懒，总把它和@RestController搞混，明明需要返回页面视图，却乱用@RestController，结果页面跳转动不动就变成返回纯字符串文本，折腾好久才搞明白，@RestController是@Controller和@ResponseBody的结合体，只适合写前后端分离的接口，不适合传统页面跳转项目。
然后就是请求映射注解，这是对接前端请求的关键。最早只用@RequestMapping，不管get还是post请求都用它，结果上线后出现过请求方式不匹配的报错。后来慢慢分开使用，@GetMapping专门处理GET查询请求，@PostMapping负责POST提交请求，精准区分请求方式，能规避很多莫名报错。还有@RequestMapping可以设置类上统一路径，方法上补充子路径，简化接口地址的书写，不用每个接口都重复写完整地址，日常开发用的最多也最实用。
参数接收类注解是踩坑最多的地方，几乎每个新手都在这里栽过跟头。刚开始接收普通参数，一直不知道用@RequestParam，直接定义参数经常出现参数名不匹配、为空报错的问题。这个注解可以绑定前端传参和后台接收参数，还能设置参数是否必填、默认值，完美解决参数接收异常。处理路径变量的时候，必须用@PathVariable，比如编辑、删除接口的id参数，不用这个注解根本拿不到路径中的动态参数。
做表单提交和实体参数接收时，试过很多错误写法，直接用实体类接收参数经常出现字段映射不全的问题。后来发现@ModelAttribute专门适配表单提交场景，能自动把表单参数封装到实体对象里，还可以在方法上加这个注解，提前封装公共参数，不用每个接口重复赋值。而接收JSON格式参数的时候，必须搭配@RequestBody，前后端分离项目里所有的POST JSON请求，少了这个注解绝对接收不到任何参数，之前就是因为漏写这个注解，调试了整整一下午接口。
还有几个辅助高频注解，看似不起眼，却是项目稳定运行的关键。@ResponseBody刚才顺带提过，单独使用时可以让方法返回值转为JSON数据，放弃页面跳转，适配数据接口开发。@RequestMapping的衍生注解之外，@CrossOrigin是解决跨域问题的神器，早期不懂配置跨域过滤器，直接在控制器类或接口方法上加这个注解，就能快速解决前端跨域请求失败的问题，临时开发、测试特别方便。
初始化项目全局配置的时候，还接触过@InitBinder和@ExceptionHandler两个注解。@InitBinder用来统一处理参数绑定，比如前端传的日期字符串，后台实体是日期类型，参数绑定会报错，用这个注解自定义转换器，就能全局统一处理日期、数字类型转换，不用每个接口单独处理。@ExceptionHandler是全局异常处理注解，在控制器中定义异常处理方法，就能捕获当前类所有接口的报错，统一返回规范的错误信息，不用每个接口都写try-catch，极大简化了代码。
很多教程会罗列一堆冷门注解，但实际企业开发中，上面这些就是全部刚需注解。其余小众注解几乎不会用到，盲目记忆只会增加负担，真正落地开发，吃透这十几个核心注解，就能搞定所有SpringMVC接口开发、页面跳转、参数处理的需求。
深夜改完最后一个接口注解报错的时候，盯着运行成功的控制台，脑子里只剩一个念头，当初刚学的时候要是只聚焦实操注解，根本不用浪费那么多时间啃无用知识点。