ssm属于前端还是后端？

SSM不是前端。它连一行浏览器能直接执行的端还代码都不管。SSM是后端Spring + Spring MVC + MyBatis的缩写，这三个东西全部跑在Java虚拟机里，于前部署在Tomcat、端还Jetty这类Web服务器上。后端用户打开浏览器看到的于前页面、点击的端还按钮、滑动的后端轮播图——那些是HTML、CSS、于前JavaScript的端还事。SSM负责的后端是：当你在地址栏敲下/user/123，服务器怎么找到对应的于前Java方法，怎么查数据库，端还怎么把数据塞进JSON里扔回去。后端这是典型的后端活儿。

有人会搞混，是因为Spring MVC里有个“MVC”。MVC是Model-View-Controller，听起来好像沾了“View”的边。但Spring MVC的“View”通常只是返回一个逻辑视图名，比如"userDetail"，然后由ViewResolver去拼成/WEB-INF/jsp/userDetail.jsp。那个JSP才是最终HTML的模板。可JSP本身也是跑在服务器上的，浏览器拿到的只是渲染完的静态HTML。SSM的Controller不写页面样式，不处理点击事件，不操作DOM。它只决定“给哪个页面”和“给什么数据”。

我见过一个典型误解。有个刚入行的朋友，简历上写“熟悉SSM前端开发”，面试官问：“你用SSM做过什么前端交互？”他答：“用JSP写表单，用jQuery发Ajax。”面试官笑了：“jQuery是前端，JSP是后端模板。SSM是后面那半截。”他这才明白，SSM里的“S”和“M”跟浏览器半毛钱关系没有。Spring管Bean的生命周期和依赖注入，MyBatis管SQL映射和结果集。这些都在服务器内存里发生。

换个角度：前端工程师需要会SSM吗？基本不需要。他们更关心React、Vue、Webpack、ES6。后端工程师需要会SSM吗？十年前是标配，现在国内中小公司还在大量用。SSM的定位很清晰——它是Java Web开发的服务端框架组合。你打开一个SSM项目的pom.xml，看到的依赖是spring-webmvc、mybatis-spring、mysql-connector-java。没有vue，没有react，没有webpack。这就够说明问题了。

那为什么有人会问“SSM属于前端还是后端”？因为前后端分离之前，Java Web项目里前后端代码是混在一起的。一个JSP文件里既有<c:forEach>标签遍历后端数据，又有onclick事件调JavaScript函数。新手看到同一个文件里又有Java又有HTML，就分不清了。但分界线不在文件，在运行位置。JSP里的Java代码在服务器上跑，JavaScript在浏览器里跑。SSM只负责前者。现在前后端分离了，后端只返回JSON，前端用Axios去取。SSM连JSP都不需要了，直接@ResponseBody返回对象。这时候更明显——SSM就是后端。

我自己的判断标准很简单：看这个技术栈能不能脱离浏览器运行。把SSM项目里的所有HTML、CSS、JS删掉，只保留Controller和Service，用Postman发请求，它照样工作。反过来，把浏览器关掉，前端代码一行都跑不了。SSM的测试用例通常用JUnit加MockMvc，模拟HTTP请求，不启动真实浏览器。这就是后端框架的典型测试方式。前端框架的测试用Jest、Cypress，跑在Node或浏览器里。

还有个小细节。SSM项目里经常出现@Controller和@RestController。前者返回视图，后者返回数据。但不管返回什么，这个类都运行在服务器端。@RequestMapping映射的是URL路径，不是浏览器路由。浏览器路由是vue-router或react-router的事。SSM的DispatcherServlet拦截的是HTTP请求，不是页面跳转。这些概念容易混淆，但拆开看，各在各的层。

所以结论很直接：SSM是后端。它处理业务逻辑、数据持久化、事务控制、安全认证。它不碰像素，不碰事件，不碰浏览器API。如果你在学SSM，你是在学后端开发。如果你在写SSM代码，你写的是服务器端程序。别被“MVC”里的“V”骗了，那个V是服务器渲染的模板，不是前端框架的组件。