简介：面向需要完成毕业设计或课程设计的Java学习者，这套基于SSM框架与MySQL数据库实现的双星小区物业管理系统，也可作为企业中小型物业信息化管理的参考案例。系统采用JSP与B/S架构，通过Maven管理依赖，后端整合Spring、SpringMVC、MyBatis三款主流框架，前端使用JSP、CSS、JavaScript完成页面呈现，并随包提供数据库脚本与毕业论文文档。系统内设管理员、员工、用户三种角色，管理员可维护用户、员工、房间、设施、收费、投诉、报修、公告以及各类型信息，员工可处理收费、投诉、报修与公告，用户可在线注册、登录并提交维修或投诉诉求，由此覆盖物业日常运营的完整核心流程。资源压缩包共包含1033个文件，总大小约11.54MB，其中Java源文件120个、JSP动态页面65个、JavaScript脚本242个、CSS样式表125个，另含大量图标图片、SQL数据库脚本及毕业论文文档，整体结构清晰，导入主流集成开发环境后即可查看运行效果。目前已有179人学习下载，对于理解SSM分层整合、角色权限控制以及物业业务建模有直接帮助；完整的源码与数据库脚本可快速搭建可运行项目，配套毕业论文也能为撰写设计文档提供思路，整体实用价值较高。

1. 一套基于SSM框架的物业管理系统源码，能直接当毕设复现的资源包长什么样

每年毕业设计节点，总有人问我有没有“能直接跑起来”的SSM框架项目。这套基于SSM框架的某小区物业管理系统源码包，就是朝这个目标去的：后端用 spring+springmvc+mybatis 老三件套，数据库用 mysql5.5+，前端是 jsp+bootstrap+layui，maven 管理依赖，整体是典型的 b/s 结构。系统装了三类角色——管理员、员工、业主用户，覆盖收费、报修、投诉、公告、留言板、房间与设施管理等小区物业日常业务。适合两类人：一类是准备拿 Java Web 做毕设，想要一套完整可复现代码的同学；另一类是已经工作，想快速搭一个SSM业务例子做参考的开发者。整套资源附带数据库脚本和毕业论文文档，省掉从零搭框架和写文档的时间，这是它最值钱的地方。

2. 选型与架构：为什么这套系统坚持用 SSM 而不是 Spring Boot

2.1 SSM 与 Spring Boot 的核心差异，以及毕设场景下的取舍

拿到这套源码后，第一个要回答的问题是：现在新项目都用 Spring Boot 了，为什么这套系统还用 SSM？直说结论：不是技术落后，是匹配场景。很多高校的毕业设计大纲里，对“框架”两个字的要求写的是 spring+springmvc+mybatis，或者直接把 SSM 列为必选；用 Spring Boot 反而要额外说明“为什么用 Spring Boot 代替 SSM”，答辩时多一个解释成本。

从实现角度看，SSM 和 Spring Boot 的本质区别在“谁帮你干活”。Spring Boot 用自动配置把大量样板配置吞掉了，你写一个 controller 就能跑；SSM 则要求你手动把 spring 容器、springmvc 的 dispatcherServlet、mybatis 的 sqlSessionFactory 一个个装配起来。这套系统把装配过程完整保留了，对学习者反而是好东西——你能清楚看到每个 bean 是怎么注册的、每个请求是怎么路由的、每条 SQL 是怎么绑定的。答辩时老师问“你的事务怎么配的”“mapper 接口怎么被扫描到的”，你都能直接指到对应的 xml 文件回答。

我对这套系统的定位判断是：它是一个“教学完整性优先”的项目，而不是“开发效率优先”的项目。它故意保留了 SSM 的经典写法：controller 层负责接收参数和转发页面，service 层处理业务逻辑，mapper 层直接写 SQL。这种分层在 Spring Boot 里被弱化了，但在 SSM 里分得很清楚。

2.2 Maven 工程结构：从 pom.xml 到 webapp 的常规摆法

项目工程用的是 Maven 标准目录，按约定优于配置的规则摆放。单模块还是多模块？这套系统采用了最常见的单模块 war 包结构，因为业务体量不大，拆多模块反而增加理解成本。拿到源码后你会看到这样的目录骨架：

src ├── main │ ├── java │ │ └── com │ │ └── demo │ │ ├── controller # 控制层，接收请求 │ │ ├── service # 业务层，接口+实现 │ │ ├── mapper # MyBatis 的 mapper 接口 │ │ ├── entity # 实体类，对应数据库表 │ │ └── interceptor # 登录拦截器等 │ ├── resources │ │ ├── spring # spring 与 mybatis 整合配置 │ │ ├── springmvc # springmvc 配置 │ │ ├── mapper # mapper 接口对应的 xml 文件 │ │ └── jdbc.properties # 数据库连接参数 │ └── webapp │ ├── WEB-INF │ │ └── jsp # 前端页面 │ ├── css │ ├── js │ └── index.jsp

第一次打开这个工程，你会在 resources 下看到 jdbc.properties，里面是数据库连接信息，包括 driver、url、username、password 四个核心参数。url 默认指向本机 mysql，端口 3306，数据库名一般是 project 或 property 之类的名字。部署前第一件事就是把这里的用户名密码改成你自己本机的。

maven 的 pom.xml 里锁定了项目基础依赖。我贴一段核心依赖片段，版本号是老 SSM 项目的经典组合，你本地 maven 仓库缺哪个会自动下载：

<!-- 打包方式为 war，配合 tomcat 发布 --> <packaging>war</packaging> <!-- spring 全家桶 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.3.30.RELEASE</version> </dependency> <!-- mybatis 与 spring 整合 --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.4.6</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>1.3.2</version> </dependency> <!-- mysql 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.47</version> </dependency>

注意 spring-webmvc 的版本是 4.3.30.RELEASE，这是 Spring 4.x 的收尾版本，和 jdk1.8、tomcat8 配合非常稳定。mybatis-spring 1.3.2 对应 mybatis 3.4.x，也是那个时期的标准搭配。使用这个资源包时，我不建议你去升级 spring 到 5.x 或 mybatis 到 3.5+，因为升级往往带来一连锁的配置兼容问题，而这套代码里很多细节是照着 4.x 的 API 写的，升级后容易踩到方法签名的坑。

2.3 前端与三层架构的分工：JSP 在 B/S 结构里承担的角色

前端部分引入了 bootstrap.min.css 和 layui.css，这是页面布局和表格弹窗的样式基础；公告与留言板部分还引入了 ueditor.css 和 ueditor.min.css，说明编辑器用的是 UEditor，用来做富文本内容的录入。JSP 页面放在 WEB-INF/jsp 下，这是比较规范的做法——WEB-INF 目录下的页面不能通过浏览器直接输入路径访问，必须经过 controller 转发，天然加了一层访问控制。

看一遍 springmvc 的配置文件，你会发现视图解析器的前缀后缀配置指向了 WEB-INF/jsp：

<!-- 视图解析器：控制层返回字符串时，拼接出真实 JSP 路径 --> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/" /> <property name="suffix" value=".jsp" /> <property name="order" value="1" /> </bean>

这段配置的意思是：controller 里 return "repair/list";，实际渲染的页面是 /WEB-INF/jsp/repair/list.jsp。prefix 和 suffix 两个参数改任何一处，所有页面的路径都会跟着变，所以不要轻易动。你还会在 controller 里看到返回 ModelAndView 或者带 Model 参数的方法，传过去的对象在 jsp 里通过 EL 表达式 ${xxx} 取出来渲染。这套系统的交互模式是典型的“页面刷新式”，每次操作表单提交后就跳转或重定向到列表页，没有前后端分离那种 ajax 刷新的流畅感，但好在结构简单，每个功能模块的代码路径都非常好找。

3. 数据库设计与角色权限：三张用户表怎么撑起整个物业系统

3.1 管理员、员工、业主三张用户表的划分与登录设计

打开数据库脚本，你会看到用户相关的表分了三张：admin（管理员）、employee（员工）、user（业主）。为什么不合成一张 user 表加 role 字段区分？这是老 SSM 项目里常见的做法，也符合这个系统的实际需求——三种角色的字段有差异：员工需要所属部门、负责区域；业主需要关联具体的房间号；管理员则基本只有账号密码和基本资料。合成一张表就得冗余很多用不到的字段，拆开反而各表干净。

员工表的核心字段大致是这样的结构：

CREATE TABLE `employee` ( `employee_id` int(11) NOT NULL AUTO_INCREMENT, `account` varchar(30) NOT NULL COMMENT '登录账号', `password` varchar(64) NOT NULL COMMENT '登录密码', `real_name` varchar(30) DEFAULT NULL COMMENT '姓名', `phone` varchar(20) DEFAULT NULL COMMENT '联系电话', `dept` varchar(50) DEFAULT NULL COMMENT '所属部门', `status` tinyint(4) DEFAULT '1' COMMENT '1在职 0离职', PRIMARY KEY (`employee_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

业主表的区别在于多了 room_id 字段，用来关联房间表，这意味着一个业主可以绑定到一个具体的房间。管理员表最简单，通常就 account、password、real_name 三个字段。登录时前端页面会让用户选择角色（管理员/员工/业主），后端根据角色参数去查对应的表。这种设计在代码层面用 if-else 分支就能实现，不需要复杂的权限框架。

登录逻辑的常见写法是：把角色代码传进来，按角色查对应表，用户名密码匹配成功后，把用户对象和角色标识一起放进 session。后面所有需要权限判断的地方，都从 session 里取角色标识来决定页面显示哪些菜单。这一点我会在第4章的拦截器部分展开。

3.2 业务表拆解：房间、收费、报修、投诉、公告五类核心表的关系

这套系统里业务最重的是收费和报修。收费表面向业主记录每一笔费用，字段设计直接影响后续统计。我建议你重点看它的状态字段设计，一个合理的收费表大概长这样：

CREATE TABLE `fee` ( `fee_id` int(11) NOT NULL AUTO_INCREMENT, `fee_type_id` int(11) DEFAULT NULL COMMENT '收费类型，关联收费类型表', `user_id` int(11) DEFAULT NULL COMMENT '业主id', `room_id` int(11) DEFAULT NULL COMMENT '房间id', `fee_money` decimal(10,2) DEFAULT NULL COMMENT '金额', `status` tinyint(4) DEFAULT '0' COMMENT '0未缴 1已缴', `create_time` datetime DEFAULT NULL COMMENT '生成时间', `pay_time` datetime DEFAULT NULL COMMENT '缴费时间', PRIMARY KEY (`fee_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

fee_money 用 decimal(10,2) 而不是 float/double，这是金钱字段的标准做法，避免浮点精度问题。status 用 tinyint 存 0 和 1，分别表示未缴和已缴，而不是直接存“未缴”“已缴”的字符串——存字符串虽然可读性好，但统计时 group by 很难受，而且表单下拉框要维护两套值。

报修表相比之下状态更复杂一些，至少要区分“待处理”“处理中”“已完成”三档：

CREATE TABLE `repair` ( `repair_id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) DEFAULT NULL COMMENT '报修业主', `room_id` int(11) DEFAULT NULL COMMENT '报修房间', `content` varchar(255) DEFAULT NULL COMMENT '报修内容', `status` tinyint(4) DEFAULT '0' COMMENT '0待处理 1处理中 2已完成', `employee_id` int(11) DEFAULT NULL COMMENT '接单员工', `create_time` datetime DEFAULT NULL COMMENT '提交时间', `handle_time` datetime DEFAULT NULL COMMENT '处理时间', PRIMARY KEY (`repair_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

注意这个表设计里 employee_id 是可空的，因为业主提交报修时还没有员工接单，要等员工在后台“接单”后才回填这个字段。这种“先空后填”的设计在业务表里很常见。你在复现时，如果发现新增报修后员工列表里看不到工单，优先检查是不是列表查询里 join 了 employee 表导致内连接把未接单的数据过滤掉了——这种问题用左连接就能解决。

公告、投诉、留言板三张表的逻辑更简单，基本都是“主表 + 类型表”的结构。公告表有公告类型外键，留言板有留言类型外键，投诉表同理。类型表本质是下拉框数据源，这种拆分让前端表单的类型选择可以直接从数据库查，不用在前端硬编码。

3.3 MyBatis 关联查询与结果映射：一对多场景的配置习惯

三张用户表、多张业务表之间的关系，落到 MyBatis 里就是 resultMap 的映射问题。以查询“某业主的报修记录并带出房间号和业主姓名”为例，mapper 接口和 xml 的常见写法是这样的：

public interface RepairMapper { // 查询报修列表，联表带出业主姓名和房间编号 List<RepairVO> selectRepairList(@Param("status") Integer status); }

对应的 xml 映射文件：

<select id="selectRepairList" resultType="com.demo.entity.RepairVO"> SELECT r.repair_id, r.content, r.status, r.create_time, u.real_name AS userName, u.room_id, ro.room_no FROM repair r LEFT JOIN user u ON r.user_id = u.user_id LEFT JOIN room ro ON u.room_id = ro.room_id <where> <if test="status != null"> AND r.status = #{status} </if> </where> ORDER BY r.create_time DESC </select>

这里有两个细节需要你注意。第一，resultType 用的是 vo 类而不是 entity 实体类，因为查询结果包含了 repair 表之外的中文名字段，实体类里没有对应属性，映射会报错。很多初学者在这里翻车：实体类加不上字段就硬加，结果把实体类搞得很脏。正确做法是单独建一个 vo 类承载联表查询结果。第二， 标签配合 实现了动态 SQL——status 有值就按状态过滤，没值就查全部，这是查询列表最常见的需求。我把这个写法当作这套系统里所有列表查询的模板，收费列表、投诉列表、员工列表基本都是一个套路。

这章最后提醒一个细节：mysql 脚本里的建表语句几乎都带 ENGINE=InnoDB DEFAULT CHARSET=utf8。InnoDB 的支持事务和外键，对于收费、报修这类需要状态流转的业务表是必须的；字符集用 utf8 而不是 utf8mb4，在老版本 mysql5.5 上兼容性更好——但如果后端做了“表情符号入库”的需求就不行了，这点在排查乱码时可以回看。

4. SSM 整合链路：从一个报修工单看请求怎么走到数据库

4.1 启动前的配置三件套：web.xml、spring.xml、springmvc.xml 分工

拿到源码后别急着跑，先清楚三个配置文件的分工，部署遇到问题才能定位。web.xml 是 web 容器的入口配置，spring 的 ContextLoaderListener 在这里注册，它负责加载 spring 容器，管理 service、mapper 这些后端 bean；同时 springmvc 的 DispatcherServlet 也在这里声明，它负责接收所有请求并分发给 controller。找个片段看：

<!-- 加载 spring 容器配置 --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring/applicationContext*.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- springmvc 前端控制器 --> <servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:springmvc/springmvc-servlet.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

url-pattern 配的是 "/" 而不是 ".do" 或 "/spring/"，意味着所有请求都走 DispatcherServlet，包括静态资源——如果 springmvc 配置里没放行 css/js 的映射，访问页面会发现样式全丢，这一点到第5章避坑部分还会再踩一次。

spring 配置文件里主要做三件事：开启注解扫描（扫 controller 之外的 bean）、配置 mybatis 的 sqlSessionFactory（数据源、mapper xml 位置、别名包）、配置事务管理器。数据源通常在 jdbc.properties 里维护，spring 配置文件用占位符引用：

<context:property-placeholder location="classpath:jdbc.properties"/> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean>

我一般会把 spring 配置拆成两份：applicationContext.xml 放公共部分，applicationContext-mybatis.xml 单独放 mybatis 整合。这套源码里如果也是这个结构，你排查问题时能缩小范围——mybatis 相关报错基本只看后面那份。

4.2 一次完整请求链路：业主提交报修，数据怎么入库

顺着一条业务线把整个 SSM 链路走一遍，比空看配置管用。以业主提交报修为例子：业主在报修页面填写内容，点提交，请求发到 RepairController 的 add 方法。controller 代码大致是这个形态：

@Controller @RequestMapping("/repair") public class RepairController { @Autowired private RepairService repairService; /** * 提交报修单 * 从 session 拿当前登录业主，避免前端伪造 user_id */ @RequestMapping(value = "/add", method = RequestMethod.POST) public String add(Repair repair, HttpSession session) { User user = (User) session.getAttribute("loginUser"); if (user == null) { return "redirect:/login"; } repair.setUserId(user.getId()); repair.setStatus(0); // 初始状态：待处理 repair.setCreateTime(new Date()); repairService.insert(repair); return "redirect:/repair/list"; } }

注意 add 方法的参数是一个 Repair 实体，SpringMVC 会自动完成请求参数到实体的绑定，前提是表单字段名和实体属性名一致。比如表单里的 input name="content"，实体里有 content 属性，就能直接映射上。但 room_id、user_id 这种不能信任前端传值——代码里显式从 session 取当前登录者再 setUserId，防止有人手动改请求参数伪造报修人。这是老项目的血泪经验，你二次开发时务必保留这个习惯。

service 层通常是接口加实现类：

public interface RepairService { void insert(Repair repair); } @Service public class RepairServiceImpl implements RepairService { @Autowired private RepairMapper repairMapper; @Override public void insert(Repair repair) { repairMapper.insert(repair); } }

最后落到 RepairMapper.xml 的 insert 语句：

<insert id="insert" parameterType="com.demo.entity.Repair"> INSERT INTO repair(user_id, room_id, content, status, employee_id, create_time, handle_time) VALUES(#{userId}, #{roomId}, #{content}, #{status}, #{employeeId}, #{createTime}, #{handleTime}) </insert>

INSERT 语句里的 #{userId} 等占位符用的是预编译方式，mybatis 会把它转成 PreparedStatement 的 ? 参数，能有效防 SQL 注入。这也是 SSM 比直接拼 SQL 的 JDBC 写法安全的地方。整个链路下来你会发现：controller 不写 SQL、mapper 只写 SQL、service 只做转调，各层职责清晰，这也是答辩时最好讲的部分——老师问“三层架构怎么体现的”，你直接把这三个类摆出来就能说明白。

4.3 登录拦截与三种角色分流：session 里到底存了什么

这套系统有三种角色，权限差异不在细粒度功能上，而是体现在菜单可见性。业主登录后能看到报修、投诉、留言板；员工登录后能看到接单、收费处理；管理员则多了员工管理、用户管理、系统设置。实现方式不是 Shiro 那一套，而是简单的登录拦截器加 session 角色判断。

拦截器是最容易出问题的部分，先看它的注册配置：

<!-- springmvc 拦截器配置 --> <mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <!-- 登录页、静态资源放行 --> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/css/**"/> <mvc:exclude-mapping path="/js/**"/> <mvc:exclude-mapping path="/images/**"/> <bean class="com.demo.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

路径匹配用 ant 风格，/**匹配所有路径，exclude-mapping 排除登录接口和静态资源。排除了 css/js 这一点非常关键，不然第一次访问页面时，样式文件全被拦截器拦下来，重定向到登录页，于是你看到的是一个“没有样式的登录页”。

拦截器内部逻辑围绕 session 判断，核心代码就是取 session 里的用户对象：

public class LoginInterceptor extends HandlerInterceptorAdapter { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object loginUser = session.getAttribute("loginUser"); if (loginUser == null) { // 未登录，重定向到登录页 response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

这里只判断“有没有登录”，不判断“是哪种角色”。角色级的菜单权限是页面通过 JSTL 标签按 session 里的角色标识渲染的。登录时存的角色标识，通常是一个字符串：admin、employee、user。后续在前端 JSP 页面里用<c:if test="${sessionScope.loginRole == 'admin'}">控制菜单显示。你想扩展“员工不能看用户管理”这类细粒度权限，就得往拦截器里加角色判断了——这个改造方向我留到第6章讲。

5. 部署使用避坑：环境、数据库脚本与路径的五个高频雷区

5.1 数据库脚本导入报错：多半死在字符集和 SQL 模式

现象：用 Navicat 导入 sql 脚本，报错 SQLException，或者导入成功但中文全部变成问号。

原因：这个脚本建表语句带中文 COMMENT，如果连接字符集不是 utf8，注释和默认值直接乱码；另外 mysql5.7+ 默认开启 ONLY_FULL_GROUP_BY 等严格模式，老脚本里某些 group by 写法会直接不通过。

解决：导入前手动建库并指定字符集，再执行脚本。命令如下：

# 在 mysql 命令行执行，先建库再指定默认字符集 CREATE DATABASE property_db DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; USE property_db; SOURCE /path/to/property_db.sql;

如果你用的是 Navicat，右键连接选“编辑连接”，在高级选项卡里把编码设为 UTF-8 再导入。导入完成后执行SHOW TABLES;确认表数量，再随机查一张业务表看中文是否正常。这一步走完，后面才能继续。

5.2 页面样式全丢：静态资源被 DispatcherServlet 拦截

现象：Tomcat 启动成功，登录页能打开，但纯 HTML 没有任何 CSS 样式，F12 控制台一堆 404，全是 .css 和 .js 文件找不到。

原因：springmvc 的 url-pattern 配成 "/" 后，所有请求都进 DispatcherServlet，包括静态资源。虽然拦截器配置排除了 css/js 路径，但如果 springmvc 配置文件里没有开启默认资源处理器，静态资源依然找不到。

解决：在 springmvc 配置文件里加两行配置：

<!-- 开启默认 Servlet 处理静态资源 --> <mvc:default-servlet-handler/>

加完后把 Tomcat 服务停掉，重新 clean 再启动，不要用热部署——静态资源配置的修改有时热部署不生效，看起来像是没改对。

5.3 页面跳转后路径全乱：根路径计算错误

现象：从登录页跳进首页后点任何菜单都 404，地址栏里的 URL 明显多了一段或少了一段，比如 /repair/list 变成了 /repair/repair/list。

原因：JSP 页面里写死了相对路径，href="css/bootstrap.min.css"这种写法在二级目录下解析时，浏览器会基于当前 URL 往上拼，路径就重复了。

解决：在所有 JSP 页面的 head 区加入 ctx 变量和 base 标签，模板如下：

<% String ctx = request.getContextPath(); request.setAttribute("ctx", ctx); %> <base href="${ctx}/">

之后所有静态资源和链接都用${ctx}/xxx来拼。这是最省事的后悔药，一劳永逸。顺手检查一下 Controller 里 redirect 的地方，尽量统一用 redirect:/ 前缀而非相对路径，避免二次重定向时路径错乱。

5.4 启动报 java.lang.NoClassDefFoundError：jar 包冲突或未发布

现象：本地 IDEA 里运行没问题，打 war 包丢到 Tomcat webapps 下启动，报 NoClassDefFoundError，常见的是 javax.servlet 或 spring 相关类找不到。

原因：Maven 管理的依赖没有正确打进 war 包，或者 Tomcat 自带的 servlet-api 和项目里的 jar 版本冲突。

解决：先检查 war 包内 WEB-INF/lib 目录是否存在且包含 spring、mybatis 等 jar。如果没有，在 pom.xml 里检查是否误将依赖 scope 设成了 provided——provided 的 jar 不会打进 war，但 tomcat 又没有对应实现时就会缺类。servlet-api 这类本来就该用 provided（容器提供），但 spring-webmvc、mybatis 这些必须是 compile 默认范围。排查命令：

# 在项目根目录执行，查看依赖树 mvn dependency:tree

重点看有没有同一个 jar 出现多个版本，MyBatis 3.4.x 和 3.5.x 同时存在时极易出 NoSuchMethodError。

5.5 登录后直接访问内页也 404：拦截器放行路径不完整

现象：登录页能打开，但输入正确账号密码后跳转内页 404，后台日志显示拦截器放行后没有对应的 controller 处理。

原因：拦截器放行了 /login 路径，但登录表单提交的路径是 /user/login 或者 /doLogin，拦截器没放行，请求被 preHandle 拦下重定向回登录页。如果 redirect 路径又写错，就表现为“登录页面反复刷新但进不去”。

解决：打开拦截器配置文件，核对登录相关路径的实际 controller 映射，把 exclude-mapping 补全。常见做法是配置两个放行路径：

<mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/user/login"/>

同时确认登录成功后的重定向地址和首页 controller 映射一致。我排查这种问题时习惯先把拦截器整个注释掉，跑通业务后再一个个放行路径加回来，这样能快速区分是拦截问题还是 controller 本身的问题。

6. 验收技巧：全角色打一遍收工，再谈两个改造方向

6.1 一套覆盖三角色的验收清单

代码跑通后，别急着传给导师，先花半小时按角色走一遍主流程。我每次拿到这种多角色系统都会做一张自测表，照着点一遍，确认没有链路是断的：

这里的核心是“角色之间要打通”。很多项目单独每个功能都能跑，但业主提交报修后员工看不到数据，本质上都是外键关联字段没对应上。我一般会直接进数据库查一条报修记录，看看 user_id 能不能对上业主表主键，这是最快定位问题的方式。

6.2 两个低成本改造方向：统计报表与权限收敛

如果你时间富余，建议做两个低成本改造，答辩时能讲出新意。

第一个是给收费模块加一个统计页，按月份 group by 收费类型统计应收、实收金额。sql 只需要在 fee 表上做聚合，前端用 ECharts 画一个柱状图，工作量大约一天。这个改造能体现你对 SQL 聚合和数据可视化的理解，属于典型加分项。

第二个是权限收敛：目前的拦截器只判断登录态，不做角色细粒度控制。可以改成自定义注解 @RequireRole("admin")，配合拦截器做方法级别的角色校验。代码改动量不大，但能把“权限设计”这个点讲清楚，比单纯说“我用 SSM 做了个增删改查”有深度得多。答辩时老师几乎必问“不同权限的人怎么隔离”，有这个注解实现后，回答就有了具体支撑。

从毕业设计文档的角度，论文的第三章“系统详细设计”可以和你代码里的包结构一一对应：controller 包对应界面层设计，service 包对应业务逻辑层，mapper 包对应数据访问层。图表截图直接贴登录流程图、报修时序图、数据库 E-R 图即可，代码里都有对应的实现。

最后说一个我的习惯。现在每次拿到这种 SSM 旧项目，我都不会直接开跑，而是先建库、再确认拦截器和静态资源配置、然后按角色把主流程走到底，全部通过后才开始动代码。这套流程帮我避过无数次“看起来能跑、实际到处是断链”的尴尬返工。希望你也能顺顺利利把它跑起来——希望帮到你。

本文还有配套的精品资源，点击获取