吃透 SSM 直接上岸！2026 大厂高频面试题全集｜源码剖析 + 生产坑点 + 实操场景
题库说明：全网最全SSM全套面试题库，整合Spring、SpringMVC、MyBatis三大核心框架，包含基础概念、底层源码、生产坑点、高频业务场景实操题、SSM整合原理，无冗余无关内容，覆盖校招、社招全阶段面试，可直接全文背诵刷题。
一、Spring框架核心概述
1. 什么是Spring？核心定位与核心特点
Spring是一款轻量级、开源、非侵入式、一站式的Java企业级开发框架，核心目标是简化企业级开发、彻底解耦组件依赖、统一Java Web开发架构，是Java生态的底层核心框架。
四大核心特点：
-
轻量级：核心框架体积仅2M左右，无重型冗余依赖，启动快、资源占用低；
-
非侵入式：业务代码无需实现Spring专属接口、无需继承框架类，移除框架后业务代码可独立运行；
-
一站式：覆盖数据层、业务层、Web层、事务、切面、测试全链路开发场景；
-
高扩展：框架的框架，可无缝集成MyBatis、Redis、消息队列等所有主流中间件。
2. Spring核心三大核心功能是什么？
Spring整个框架的核心基石为三点，所有功能均基于此拓展：
-
IoC 控制反转：核心解耦思想，容器统一管理对象创建与依赖，彻底解决代码耦合问题；
-
AOP 面向切面编程：无侵入增强方法，统一封装日志、事务、权限、限流等通用横切逻辑；
-
声明式事务管理：基于AOP实现统一事务管控，简化数据库事务开发，保证数据一致性。
3. Spring完整模块架构及核心模块作用
Spring采用分层模块化架构，各模块职责解耦、按需引入，是Spring全家桶的底层支撑：
| 核心容器（底层基石） | Core、Bean、Context、SpEL | 实现IoC容器、Bean生命周期管理、资源加载、Spring表达式解析 |
| 数据访问与集成 | JDBC、ORM、Transaction | 简化数据库操作、整合持久层框架、统一事务管理 |
| Web开发模块 | Web、Web-Servlet | 支撑SpringMVC、Web请求处理、HTTP协议适配 |
| AOP切面模块 | AOP、Aspects | 提供动态代理、切面织入、方法增强能力 |
| 测试模块 | Test | 支持Spring项目单元测试、集成测试、Mock测试 |
4. 使用Spring的核心优势
-
彻底解耦：IoC容器接管对象依赖，组件之间低耦合，代码维护性极强；
-
代码复用：AOP抽取通用逻辑，全局统一管控，消除代码冗余；
-
简化开发：提供大量工具类、模板类，规避原生Java、JDBC繁琐代码；
-
易于测试：依赖注入机制支持灵活Mock依赖，单元测试成本极低；
-
生态强大：无缝兼容所有主流技术栈，适配绝大多数企业级业务场景；
-
架构规范：强制分层解耦，统一团队开发规范，避免代码混乱。
二、IoC与DI核心原理（高频必考）
5. 什么是IoC控制反转？核心思想
IoC（Inversion of Control，控制反转）是Spring的核心设计思想，颠覆了传统对象创建与管理模式。
传统开发：开发者主动new对象、管理依赖、维护生命周期，控制权在程序员手中；
IoC开发：将对象的创建、赋值、销毁、依赖管理全部交给Spring IoC容器，开发者直接获取对象使用。
核心反转点：对象的控制权从开发者反转到Spring容器，实现组件彻底解耦。
6. 什么是DI依赖注入？三种注入方式详解
DI（Dependency Injection，依赖注入）是IoC的唯一实现手段，容器自动将Bean所需的依赖对象主动注入，无需手动创建依赖。
| 构造器注入（官方推荐） | 依赖不可变、必填依赖强制校验、线程安全、无循环依赖隐患、适配单元测试 | 依赖过多时参数冗长 | 核心业务Bean、生产首选 |
| Setter注入 | 支持可选依赖、可动态修改依赖 | 易出现空指针、依赖状态不固定 | 非必填、动态变更依赖 |
| 字段注入 | 代码简洁、开发高效 | 隐藏依赖、不利于测试、易产生循环依赖 | 简单快速开发场景 |
| 官方规范：Spring强制推荐构造器注入，保证Bean初始化依赖完备、线程安全。 |
7. IoC和DI的关系
IoC是设计思想（目标）：实现控制权反转、组件解耦；
DI是实现手段（落地）：通过依赖注入完成IoC的全部逻辑；
通俗总结：IoC是指导思想，DI是具体做法，二者一体，无DI则无法实现IoC。
8. BeanFactory和ApplicationContext的区别
BeanFactory是Spring IoC顶层根接口，ApplicationContext是其超强扩展实现，也是项目唯一使用的容器。
| 加载机制 | 懒加载，使用Bean时才实例化 | 即时加载，启动一次性初始化单例Bean |
| 功能范围 | 仅基础IoC、Bean获取功能 | 扩展事件、国际化、资源加载、AOP、事务等全套能力 |
| 适用场景 | 极简资源受限环境（几乎不用） | 所有企业级Web项目（唯一选型） |
三、Spring Bean核心原理（基础+源码）
9. Spring Bean完整生命周期（必背）
完整流程：实例化 → 依赖注入 → Aware回调 → 前置后置处理器 → 初始化 → 就绪使用 → 容器关闭销毁
实例化：通过构造器/工厂方法创建Bean空对象；
依赖注入：完成属性赋值、依赖自动注入；
Aware接口回调：Bean感知容器信息（BeanName、BeanFactory、ApplicationContext）；
BeanPostProcessor前置处理：后置处理器对Bean进行前置增强；
初始化方法执行：@PostConstruct → InitializingBean自定义初始化逻辑；
BeanPostProcessor后置处理：完成最终增强（AOP代理在此阶段生成）；
就绪使用：Bean完全初始化，存入容器缓存，对外提供服务；
销毁：容器关闭时执行@PreDestroy、DisposableBean销毁方法。
10. Bean五大作用域详解及生产选型
| singleton（默认） | 容器全局唯一实例，启动创建、关闭销毁 | 99%无状态Bean（Service、Controller、Dao） |
| prototype（多例） | 每次获取均创建全新实例，容器不管理销毁 | 有状态、需独立实例的业务Bean |
| request | 单次HTTP请求一个实例，请求结束销毁 | 存储请求级临时数据 |
| session | 单个用户会话一个实例，会话过期销毁 | 存储用户会话、登录状态 |
| application | 整个项目全局唯一实例 | 全局公共配置、静态资源 |
11. Spring Bean默认单例的原因？
-
性能最优：避免频繁创建销毁对象，减少JVM GC压力与内存开销；
-
业务适配：绝大多数核心Bean为无状态Bean，无需多实例；
-
响应更快：启动一次性初始化完成，无需每次请求重复创建；
-
内存高效：复用JVM内存分配机制，资源利用率更高。
12. 单例Bean线程安全问题及解决方案
核心结论：单例Bean不一定线程安全，无可变实例变量则线程安全，存在可变成员变量则线程不安全。
生产解决方案：
最佳实践：禁止在单例Bean中定义可变实例变量，临时数据存入方法局部变量；
使用ThreadLocal实现线程变量隔离；
修改作用域为prototype多例；
对并发代码块加锁（不推荐，影响性能）。
四、Spring AOP核心原理（必考）
13. 什么是AOP？核心作用与核心术语
AOP（面向切面编程）是横向增强的编程思想，基于动态代理，不修改源代码即可对方法进行增强，实现横切逻辑与业务逻辑解耦。
| 切面Aspect | 封装横切逻辑的类 | 日志切面、事务切面、权限切面 |
| 连接点JoinPoint | 可被切面拦截的所有点位 | 所有业务方法执行 |
| 切点Pointcut | 通过表达式筛选的目标拦截方法 | execution(* com.service..(…)) |
| 通知Advice | 切面具体增强逻辑 | 前置校验、后置日志、异常回滚 |
| 织入Weaving | 切面逻辑绑定目标方法的过程 | Spring运行时动态织入 |
14. AOP五种通知类型及执行顺序
| @Before | 方法执行前 | 权限校验、参数校验、请求日志 |
| @AfterReturning | 方法正常返回后 | 记录成功业务日志、数据统计 |
| @AfterThrowing | 方法抛出异常时 | 异常告警、事务回滚、错误记录 |
| @After | 方法执行完成（无论异常） | 资源释放、连接关闭 |
| @Around | 包裹目标方法，全权控制执行 | 性能监控、限流、缓存、全链路日志 |
| 标准执行顺序：@Around前置 → @Before → 目标方法 → @After → @AfterReturning/@AfterThrowing → @Around后置 |
15. JDK动态代理与CGLIB代理核心区别
| 代理限制 | 仅支持代理实现接口的类 | 支持代理普通类、无接口类（继承实现） |
| 实现原理 | Java反射机制 | ASM字节码动态生成子类 |
| 性能 | 反射开销大，性能偏低 | 直接字节码调用，性能更高 |
| 方法限制 | 无final方法限制 | 无法代理final方法 |
| Spring选择规则 | 有接口默认使用 | 无接口自动降级使用 |
五、Spring事务管理（高频面试TOP）
16. 七种事务传播行为详解与生产场景
| REQUIRED（默认） | 有事务加入，无事务新建 | 90%常规增删改业务 |
| REQUIRES_NEW | 强制新建独立事务，挂起原有事务 | 独立日志、异步操作、不随主事务回滚业务 |
| SUPPORTS | 有事务加入，无事务非事务执行 | 纯查询业务 |
| NOT_SUPPORTED | 强制非事务执行，挂起当前事务 | 耗时统计、无需事务的查询 |
| MANDATORY | 必须在事务内执行，无事务抛异常 | 核心子业务，依赖主事务 |
| NEVER | 强制非事务，存在事务则抛异常 | 禁止事务的缓存查询、统计接口 |
| NESTED | 有事务则嵌套（支持保存点），无则新建 | 子业务可独立回滚场景 |
17. 四大事务隔离级别及脏读/不可重复读/幻读解决
| READ_UNCOMMITTED | 允许 | 允许 | 允许 | 无 |
| READ_COMMITTED | 禁止 | 允许 | 允许 | Oracle |
| REPEATABLE_READ | 禁止 | 禁止 | 允许 | MySQL（默认） |
| SERIALIZABLE | 禁止 | 禁止 | 禁止 | 极少使用（性能极低） |
18. Spring事务10大失效场景（生产高频坑点）
Spring事务基于AOP动态代理实现，所有失效场景均为代理失效、规则不匹配导致：
同类方法内部自调用：不走代理，事务完全失效；
异常被try-catch手动捕获：无抛出异常，Spring无法触发回滚；
抛出普通Exception：默认仅回滚RuntimeException，需指定rollbackFor；
方法非public修饰：AOP无法拦截，注解失效；
数据库引擎不支持事务：MyISAM无事务能力，必须使用InnoDB；
传播行为配置错误：配置NOT_SUPPORTED、NEVER等非事务行为；
手动new对象调用方法：非容器Bean，无代理增强；
多线程调用事务方法：子线程独立事务，主线程无法回滚；
开启readOnly只读事务执行写操作：直接报错事务失效；
事务超时：执行超时自动终止，事务失效。
六、Spring循环依赖（源码级高频考点）
19. 什么是循环依赖？哪些场景可以解决？
循环依赖指两个或多个Bean互相依赖，形成闭环依赖关系（A依赖B、B依赖A）。
可解决：字段注入、Setter注入的单例Bean循环依赖；
不可解决：构造器注入循环依赖、多例Bean循环依赖。
20. Spring三级缓存源码机制详解
核心原理：提前暴露半成品Bean引用，解决单例Bean循环依赖问题。
| 一级缓存 | singletonObjects | 完全初始化的成品Bean | 对外提供可用Bean实例 |
| 二级缓存 | earlySingletonObjects | 半成品普通Bean实例 | 提前暴露普通Bean引用，避免重复创建 |
| 三级缓存 | singletonFactories | Bean工厂ObjectFactory | 生成代理Bean引用，解决代理类循环依赖 |
21. 为什么构造器注入无法解决循环依赖？
构造器注入的依赖需要在Bean实例化阶段就必须完全就绪，而三级缓存需要Bean先完成实例化才能存入缓存、暴露引用。构造器循环依赖时双方均无法完成实例化，无法进入缓存流程，因此只能通过代码重构打破依赖闭环。
七、Spring核心注解高频面试
22. 组件注解区别（@Component/@Service/@Controller/@Repository）
四个注解底层功能完全一致，都是将类交给Spring容器管理，仅用于分层语义区分：
-
@Component：通用公共组件、工具类；
-
@Service：业务逻辑层专用；
-
@Controller：Web请求控制层专用；
-
@Repository：数据访问层专用。
23. @Autowired和@Resource核心区别（必考）
| 来源 | Spring自定义注解 | JSR-250 Java标准注解 |
| 默认注入规则 | byType 按类型注入 | byName 按名称注入 |
| 依赖匹配规则 | 优先按类型，多Bean时需配合@Qualifier指定名称 | 优先按名称，名称匹配失败再按类型 |
| 必填校验 | 默认必填，可设置required=false非必填 | 无必填强制校验 |
| 使用场景 | 项目主流首选，适配Spring全套特性 | 追求Java标准、解耦框架依赖场景 |
24. @Configuration、@Bean注解原理与使用
@Configuration用于标记配置类，替代传统XML配置文件，配合@Bean实现手动注册Bean到Spring容器。
核心特性（Full模式 vs Lite模式）：
-
被**@Configuration**修饰：Full模式，内部@Bean方法会被CGLIB代理，调用方法直接从容器取Bean，保证单例；
-
仅被**@Component**修饰：Lite模式，无代理，多次调用@Bean方法会多次new对象，无法保证单例。
生产场景：第三方组件注册（RedisTemplate、Mybatis插件、线程池等）、自定义Bean初始化参数。
25. @Conditional系列注解作用
Spring条件注解，满足指定条件才注册Bean，是SpringBoot自动配置底层核心原理。
-
@ConditionalOnClass：存在指定类时才加载Bean；
-
@ConditionalOnMissingClass：不存在指定类时加载；
-
@ConditionalOnBean：容器存在指定Bean时加载；
-
@ConditionalOnMissingBean：容器无指定Bean时加载（自定义覆盖默认配置核心）；
-
@ConditionalOnProperty：配置文件满足对应参数时生效。
八、SpringMVC 全套高频面试题（核心+原理+坑点）
26. 什么是SpringMVC？核心作用
SpringMVC是Spring生态的Web层MVC框架，基于Servlet实现，用于接收前端HTTP请求、参数解析、业务调度、视图渲染、返回响应，是SSM架构的Web核心，彻底替代原生Servlet繁琐开发。
核心优势：轻量、注解驱动、请求响应封装完善、无缝整合Spring、适配RESTful风格、参数自动绑定。
27. SpringMVC完整执行流程（必背流程图解）
核心九大执行步骤，全程由DispatcherServlet前端控制器统一调度：
请求接收：前端发起HTTP请求，Tomcat拦截，交由DispatcherServlet接收；
处理器映射：DispatcherServlet调用HandlerMapping，根据URL匹配对应的Controller处理器；
获取处理器执行链：封装处理器+拦截器，生成HandlerExecutionChain；
处理器适配器适配：DispatcherServlet调用HandlerAdapter，适配对应Controller执行规则；
拦截器前置处理：执行自定义HandlerInterceptor的preHandle方法；
目标方法执行：适配器反射执行Controller目标方法，完成参数绑定、业务调用；
视图解析：方法返回ModelAndView后，ViewResolver解析视图路径（前后端分离项目直接返回JSON，无视图解析）；
拦截器后置处理：执行postHandle方法；
响应返回：渲染视图/返回JSON数据，执行afterCompletion，请求结束。
28. SpringMVC核心组件作用
| DispatcherServlet（前端控制器） | 全局请求统一入口、统一调度所有组件、分发请求、统一响应，核心总指挥 |
| HandlerMapping（处理器映射器） | 根据请求URL、请求方式，匹配对应的Controller处理器方法 |
| HandlerAdapter（处理器适配器） | 适配不同类型的处理器，统一执行规则，反射调用目标方法 |
| ViewResolver（视图解析器） | 解析视图名称，拼接前后缀，定位页面资源（前后端分离基本废弃） |
| HandlerInterceptor（拦截器） | 请求拦截，实现登录校验、权限控制、日志记录、限流等通用逻辑 |
| MultipartResolver | 文件上传解析器，专门处理multipart/form-data文件上传请求 |
| ExceptionHandler | 全局异常处理器，统一捕获、处理项目所有异常 |
29. 拦截器和过滤器的核心区别（高频对比）
| 所属层级 | Servlet层级，Java Web原生组件 | SpringMVC层级，框架自定义组件 |
| 执行时机 | 请求进入DispatcherServlet之前、响应返回客户端之后 | DispatcherServlet分发之后，Controller方法前后 |
| 依赖容器 | 依赖Tomcat容器，不依赖Spring | 依赖Spring容器，可注入Spring Bean |
| 拦截范围 | 拦截所有请求（静态资源、动态接口） | 仅拦截Controller接口请求，不拦截静态资源 |
| 使用场景 | 编码过滤、跨域处理、全局请求预处理 | 登录校验、权限拦截、接口日志、token校验 |
30. SpringMVC参数绑定原理与常见问题
底层核心：HandlerAdapter通过反射+参数解析器，将请求参数自动绑定到方法形参。
常用参数绑定场景：
-
普通参数：直接绑定基本数据类型、String，参数名与请求参数名一致；
-
实体类参数：前端参数名与实体类属性名一致，自动封装对象；
-
@RequestParam：绑定普通参数，解决参数名不一致、必填设置；
-
@PathVariable：绑定URL路径变量，适配RESTful接口；
-
@RequestBody：解析JSON格式请求体，绑定实体类（POST请求专用）。
常见坑点：GET请求无法使用@RequestBody、POST表单无法使用@RequestBody、参数名不一致导致绑定失败、日期格式不匹配报错。
31. @ResponseBody、@RestController原理
-
@ResponseBody：将方法返回值自动转为JSON字符串，写入响应体，不跳转页面；
-
@RestController：@Controller + @ResponseBody组合注解，类上所有方法默认返回JSON，适配前后端分离开发；
-
底层依赖：SpringMVC内置Jackson转换器，实现对象与JSON互转。
32. SpringMVC乱码解决方案
核心统一配置：在web.xml中配置CharacterEncodingFilter，强制设置请求、响应编码为UTF-8，解决GET/POST全局乱码问题。
九、MyBatis 全套核心面试题（基础+源码+坑点）
33. 什么是MyBatis？核心优势
MyBatis是一款轻量级、半自动、开源的持久层框架，用于替代原生JDBC，简化数据库CRUD操作，支持自定义SQL、灵活映射，是SSM架构数据层核心框架。
核心优势：
-
SQL与代码分离，解耦性强、便于维护、方便SQL优化；
-
底层封装JDBC，无需手动加载驱动、创建连接、关闭资源；
-
支持动态SQL，灵活适配多条件查询；
-
自动结果集映射，支持实体类、Map、List封装；
-
轻量无侵入、性能高、适配所有数据库。
34. MyBatis和JDBC、Hibernate的区别
| MyBatis vs JDBC | JDBC原生代码繁琐、资源手动管理；MyBatis封装JDBC，自动管理连接、结果映射、参数预编译，杜绝SQL注入 | 所有企业级项目优先MyBatis |
| MyBatis vs Hibernate | MyBatis半自动、手写SQL、灵活度高、易优化；Hibernate全自动ORM、无需写SQL、固化难优化、笨重低效 | 复杂业务、需SQL优化选MyBatis |
35. MyBatis核心执行流程（必背）
加载配置文件：读取mybatis核心配置文件、Mapper映射文件；
构建SqlSessionFactory：通过SqlSessionFactoryBuilder解析配置，创建会话工厂；
获取SqlSession：工厂开启数据库会话，包含数据库连接、事务环境；
获取Mapper代理对象：动态代理生成Mapper接口实现类；
执行SQL：代理对象调用方法，封装参数、执行预编译SQL；
结果映射：将ResultSet结果集自动映射为Java实体对象；
关闭资源：关闭SqlSession、释放数据库连接。
36. MyBatis核心组件及作用
-
SqlSessionFactoryBuilder：配置解析器，唯一作用是构建SqlSessionFactory，用完即弃；
-
SqlSessionFactory：会话工厂，全局单例，用于创建SqlSession，全局唯一；
-
SqlSession：数据库会话，包含CRUD方法、事务操作，线程不安全，用完关闭；
-
Mapper接口+Mapper.xml：定义数据库操作方法、编写SQL语句；
-
Executor执行器：MyBatis底层SQL执行核心，包含简单、复用、批量执行器。
37. MyBatis #{} 和 ${} 核心区别（必考）
| 编译方式 | JDBC预编译PreparedStatement，参数占位 | 直接字符串拼接SQL，无预编译 |
| SQL注入 | 彻底杜绝SQL注入，安全 | 存在SQL注入风险，不安全 |
| 参数处理 | 自动添加单引号，适配字符串、数字 | 直接原样拼接，不会自动加单引号 |
| 使用场景 | 普通参数查询、新增、修改（99%场景） | 动态表名、动态排序字段（极少场景） |
| 生产规范：优先使用#{}，严禁随意使用${}，必须使用时做好参数过滤防注入。 |
38. MyBatis动态SQL标签大全及场景
动态SQL解决多条件拼接、空参拼接多余and/or、动态更新字段等问题，是MyBatis核心特性：
-
：条件判断，满足条件拼接SQL，最常用；
-
：自动去除多余前缀and/or，自动拼接where关键字；
-
：更新语句专用，自动去除尾部多余逗号；
-
：遍历集合，用于in查询、批量新增/批量删除；
-
//：多条件分支，类似if-else if-else；
-
：自定义前后缀截取，灵活处理多余字符。
39. MyBatis一级缓存、二级缓存原理与区别
缓存作用：减少重复SQL查询，减轻数据库压力，提升接口响应速度。
| 一级缓存 | SqlSession级别（单次数据库会话） | 同一会话、相同SQL参数，二次查询走缓存；增删改、关闭会话清空缓存 | 开启 |
| 二级缓存 | Mapper命名空间级别（跨会话、全局） | 多个SqlSession共享缓存，增删改清空对应Mapper缓存 | 关闭 |
| 二级缓存开启条件：全局配置开启、Mapper文件配置、实体类实现序列化接口。 |
40. MyBatis延迟加载原理与使用场景
延迟加载（懒加载）：针对一对一、一对多关联查询，默认只查询主表数据，使用从表数据时才触发子查询，提升查询性能。
核心配置：开启lazyLoadingEnabled延迟加载、关闭aggressiveLazyLoading积极加载。
适用场景：关联数据量大、非必展示的关联字段，避免一次性查询大量冗余数据。
41. MyBatis常见生产坑点
Mapper接口方法名与xml id不一致，导致绑定失败；
实体类属性名与数据库字段名不一致，未配置映射导致查询为null；
动态SQL未使用，出现多余and/or导致SQL报错；
使用${}导致SQL注入漏洞；
一级缓存导致同会话读取旧数据，未实时刷新；
批量操作未使用Batch执行器，频繁交互数据库性能低下；
关联查询未开启懒加载，导致查询数据冗余、接口卡顿。
十、SSM整合核心原理面试题
42. SSM整合整体架构与职责分工
SSM = Spring + SpringMVC + MyBatis，分层解耦、各司其职，是传统Java Web企业级标准架构：
-
Spring：全局容器，管理所有Bean、统一事务、AOP增强、依赖注入，统筹全局；
-
SpringMVC：Web层框架，负责接收前端请求、参数解析、接口调度、返回响应；
-
MyBatis：数据层框架，负责数据库CRUD、SQL执行、结果集映射。
43. SSM整合核心配置流程
Spring整合MyBatis：Spring容器管理SqlSessionFactory、MapperScannerConfigurer，自动扫描Mapper接口，将Mapper代理对象注入Service；
Spring整合SpringMVC：SpringMVC容器继承Spring父容器，共享Bean，DispatcherServlet接管Web请求；
事务整合：Spring配置事务管理器，开启注解事务，作用于Service层方法；
全局初始化：web.xml配置监听器、前端控制器、编码过滤器，完成项目启动初始化。
44. Spring父子容器机制（SSM核心原理）
SSM启动存在两个Spring容器：
-
父容器（Root容器）：Spring核心容器，加载Service、Dao、事务、数据源等全局Bean，全局唯一；
-
子容器（Web容器）：SpringMVC容器，仅加载Controller、Web相关组件；
容器特性：子容器可以访问父容器Bean，父容器无法访问子容器Bean，彻底实现Web层与业务层解耦。
十一、SSM高频业务场景面试题（生产实操必考）
45. 场景一：SSM实现用户登录认证功能（完整业务流程）
业务需求：前端传入用户名密码，后端校验账号密码、记录登录状态、返回登录结果。
SSM实现流程：
Controller层：接收前端用户名、密码参数，调用Service登录方法；
Service层：调用Dao根据用户名查询用户信息，判断用户是否存在、密码是否匹配；密码匹配成功后，将用户信息存入Session/Token，返回登录成功；
Dao/Mapper层：编写selectByUsername SQL，查询用户数据；
拦截器增强：自定义登录拦截器，拦截所有需要权限的接口，校验Session/Token，未登录直接拦截跳转/返回提示。
坑点解决：密码加密存储（MD5/SHA256）、防止重复登录、参数空校验、异常捕获。
46. 场景二：SSM实现批量新增/批量修改数据
业务场景：批量导入用户、批量修改订单状态、批量更新商品信息。
MyBatis实现方案：使用标签遍历集合，拼接批量SQL。
生产优化：禁止循环单次insert（频繁交互数据库性能极差），统一使用批量SQL；大数据量拆分批次，避免SQL过长报错；开启MyBatis Batch执行器提升批量性能。
47. 场景三：SSM事务失效线上问题排查（真实生产）
场景描述：Service层方法添加@Transactional注解，新增多条数据，中间报错数据未回滚。
排查思路：
检查方法是否为public（非public无法被AOP拦截）；
检查异常是否被try-catch手动捕获，未抛出异常；
检查抛出异常类型，是否为普通Exception（默认只回滚运行时异常）；
检查是否同类方法自调用，绕过代理；
检查数据库引擎是否为InnoDB（MyISAM无事务）。
48. 场景四：SSM接口高并发查询卡顿优化方案
业务问题：数据库数据量大，频繁查询接口响应慢、数据库压力高。
SSM分层优化方案：
-
Dao层优化：优化SQL、建立索引、避免select *、分页查询、开启MyBatis二级缓存；
-
Service层优化：添加Redis缓存，缓存热点数据，减少数据库查询；
-
Web层优化：拦截器做请求限流、重复请求拦截；
-
数据库优化：读写分离、分库分表、批量操作替代循环操作。
49. 场景五：SSM实现文件上传功能
核心实现：
SpringMVC配置MultipartResolver文件上传解析器，设置文件大小、缓存阈值；
Controller方法使用MultipartFile接收前端文件；
后端校验文件格式、大小、后缀，防止恶意文件上传；
生成唯一文件名，避免文件覆盖，上传至服务器/OSS；
文件路径存入数据库，完成业务关联。
50. 场景六：SSM全局异常统一处理业务
业务痛点：代码多处try-catch、异常返回格式不统一、前端难以处理。
解决方案：基于SpringMVC**@ControllerAdvice + @ExceptionHandler**实现全局异常处理：
-
拦截项目所有Controller异常，统一封装返回结果；
-
区分业务异常、系统异常，自定义错误码、错误信息；
-
统一日志打印，便于线上问题排查；
-
杜绝前端直接展示服务器原生报错信息，提升安全性。
十二、SSM面试高频总结（压轴必背）
51. SSM架构优势与适用场景
-
分层清晰：Controller/Web、Service业务、Dao数据层，职责单一，易于维护；
-
解耦性强：Spring IoC+AOP彻底解耦，业务与通用逻辑分离；
-
SQL可控：MyBatis手写SQL，灵活优化，适配复杂业务；
-
生态成熟：企业使用率极高、文档丰富、坑点明确、适配传统项目迭代。
52. SSM项目常见线上问题汇总
-
事务失效导致数据不一致；
-
SQL编写不规范导致慢查询、数据库压力大；
-
单例Bean可变变量导致线程安全问题；
-
未做参数校验导致脏数据、非法请求；
-
缓存使用不当导致数据一致性问题；
-
请求拦截缺失导致未授权访问。
