ssm框架前后端数据如何交互

SSM框架（Spring + Spring MVC + MyBatis）的架前数据交互，说白了就是后端何交互一场“前端发快递，后端拆包裹”的数据接力赛。前端把用户操作打包成HTTP请求，架前后端通过Controller拆包、后端何交互Service处理、数据Mapper查库，架前再原路把结果返回给前端。后端何交互整个过程的数据核心只有一句话：**数据格式统一，路径映射准确，架前状态码清晰**。后端何交互

先看前端怎么把数据送出去。数据最常见的架前方式是Ajax，比如用jQuery的后端何交互$.ajax()或axios发POST请求，数据序列化成JSON字符串，数据放在请求体里。举个例子，用户提交登录表单，前端代码会这样写：$.post("/user/login", { "username": "admin", "password": "123456"})。Spring MVC的Controller层用@RequestBody注解接收，Jackson库自动把JSON转成Java对象。这里有个坑——如果前端传的字段名和后端实体类属性名对不上，直接报400错误，我调试过最蠢的一次是前端传userName，后端写的是username，找了半小时。

后端返回数据又是另一套逻辑。Controller处理完业务，返回一个对象，Spring MVC默认用Jackson把对象序列化成JSON。但如果你用了@ResponseBody注解，返回值就直接写进响应体；没加的话，Spring会找对应的JSP或Thymeleaf模板渲染页面。很多新手在这混淆——想返回JSON却忘了加注解，结果浏览器收到一坨HTML源码。我的习惯是统一用@RestController，省得每个方法都写@ResponseBody。

再说说MyBatis这层。它负责和数据库打交道，但它的参数传递经常让人抓狂。比如你要按条件查用户列表，前端传来的参数可能是{ "page": 1, "size": 10, "keyword": "张"}。Controller接收后，得手动把这些参数塞进一个Map或者实体类，再传给Mapper接口。Mapper里的SQL用#{ page}这种占位符引用，MyBatis底层用PreparedStatement预编译，防止SQL注入。有个细节：如果前端传的是数组或List，SQL里要用标签遍历，不然你拼不好IN子句。

交互过程中，异常处理是重灾区。前端传了个非法ID，后端查不到数据，如果直接返回null，前端拿到后还得自己判空。更恶心的场景是后端抛了个空指针异常，默认情况下Spring会返回一个500错误页，前端Ajax的error回调被触发，但用户看到的只是“服务器内部错误”——这体验太差了。我一般会在全局异常处理器（@ControllerAdvice）里统一捕获异常，包装成{ "code": 500, "message": "参数异常，请检查"}这样的JSON结构，前端拿到后弹个alert就行。

还有个容易忽略的点是数据格式的协商。默认情况下，Spring MVC用Jackson处理JSON，但如果你引入了XML依赖，或者前端请求头写了Accept: application/xml，Spring会尝试返回XML。我遇到过一次诡异问题：前端用axios默认请求头，后端返回JSON没问题；但换了某个老系统用ActiveX控件发请求，自动带上了XML的Accept头，后端直接报415。解决办法是配置MappingJackson2HttpMessageConverter并设置支持的MediaType，或者干脆在Controller方法上强制指定produces = "application/json;charset=UTF-8"。

最后提一嘴文件上传这种特殊交互。表单里enctype="multipart/form-data"，后端用MultipartFile接收，这跟前端传普通JSON完全不是一套逻辑。我用SSM做过图片上传，前端FormData对象里append文件，后端Controller方法参数加@RequestParam("file") MultipartFile file，然后调用file.transferTo()存盘。但要注意，Spring MVC默认上传大小限制是1MB，超过就报错，得在spring-mvc.xml里配置multipartResolver的maxUploadSize属性。

说到底，SSM的数据交互没有玄学，就是三个环节的配合：前端把数据塞进HTTP协议，Spring MVC负责协议解析和对象转换，MyBatis把Java对象映射成SQL参数。只要记住每条数据流都有明确的入口和出口，调试时用浏览器F12看Network面板，看请求参数和响应体，问题基本能定位个八九不离十。