基于SSM的商铺租赁管理系统毕业设计全解析

1. 项目概述与核心诉求解析

1.1 为什么“商铺租赁管理”是毕业设计的好选题

每年到毕业季，都有大量同学在选题上犯难：又要工作量饱满、又要技术点常规、又要答辩时能讲清楚。我这些年看过不少毕业设计，“门面商铺租赁管理系统”这个选题，从我个人的评价标准看，属于那种“看起来不惊艳、但实际做下来最稳妥”的典型代表，特别适合用 SSM 这类主流 Java 框架来落地。

先说说这个选题的业务逻辑。商铺租赁听起来只是“房东出租门面、租客按月交租”，但把它抽成系统需求，你会发现这是一个非常完整的业务闭环：房源信息登记、租客资料管理、合同签订与续签、租金台账记录、到期预警、空置商铺统计、公告发布、后台管理员权限控制……这些功能每一个都不复杂，但串起来之后就组成了一个需求边界非常清晰、表结构天然稳定、功能点覆盖全面的管理系统。这种“麻雀虽小、五脏俱全”的特质，恰好是毕业设计最需要的东西——既不会因为业务太复杂导致你做一半就放弃，也不会因为功能太少导致论文和答辩没什么可讲。

另外一个现实因素是，商铺租赁管理系统的角色划分非常清楚：管理员和租客（或者商户）。不同的角色看到的数据和能执行的操作天然不同，这就逼着你必须去实现登录认证和权限拦截，而权限控制恰恰是评委老师最爱问、也最能体现系统设计能力的技术点。如果你选的是“图书管理系统”，权限无非就是管理员和普通读者；但商铺租赁里，租客要能查看自己的合同和缴费记录，管理员要能管理所有商铺和租约，这种“多角色数据隔离”的需求，能让你的系统在业务逻辑上显得更有说服力。

1.2 这套系统的目标用户和核心价值

从使用方角度来拆，这套系统的用户画像其实非常典型。一种是商铺资产的运营方（比如某商业管理公司、某房东个人），他们需要掌握名下所有门面的租赁状态、合同到期时间、租金收缴情况；另一种是租户/商家，比如开奶茶店的、开便利店的个体经营者，他们需要知道自己每一期租金应该交多少、合同什么时候到期、有哪些公告通知。

把这个场景放到系统里，目标就很明确了：

• 对管理员：有了系统之后，不用再翻 Excel 表去查“哪个铺子快到期了”，系统自动筛选展示预警列表，哪些门面空置、哪些租约临期一眼可见。
• 对租客：登录后能看到自己的合同详情、租金缴纳历史、剩余租期，减少催缴和线下沟通成本。
• 对整个业务：租金台账全部线上留痕，每一笔收款都有记录且不可随意篡改，年底统计收入的时候直接导出报表，不用人工汇总。

我在给一些小伙伴改论文的时候经常说一句话：毕业设计的核心不是“你用了多牛的技术”，而是“你用合理的技术，把一个业务问题解决得清清楚楚”。这个项目完美踩中这一点。

适合参考这个选题的人群也很明确：Java 基础还算扎实、但苦于不知道做什么完整项目的大三、大四学生；准备专升本或考研复试需要作品集的同学；以及想快速熟悉 SSM 整合流程、想厘清框架之间到底怎么协作的初学者。如果你是这三种人之一，这篇文章后面的内容基本可以照着走。

2. 技术选型与架构设计剖析

2.1 SSM 三件套各自在项目中扮演的角色

既然项目名字里带了“SSM”，那就必须先把这个经典组合聊透。SSM 是 Spring、SpringMVC、MyBatis 三个框架的缩写，这套组合在很多年时间里是 Java 企业级开发的主流标配，也是国内高校教学中覆盖面最广的一套技术栈，直到今天依然是很多毕设系统的首选。

要理解为什么选它们，必须先搞清楚这三个框架在本系统里分别干了什么活，我尽量用大白话讲：

• Spring 是整个系统的“大管家”。它通过 IoC（控制反转）和 AOP（面向切面编程）来管理项目中所有对象的创建和依赖关系。在你的项目里，Service 层对象、DAO 层对象都在 Spring 容器里装配，你不用手动 new，需要的时候直接注入就行。更进一步，Spring 还接管了数据库事务——比如在“签订合同”这个操作里，可能要同时插入合同记录、修改商铺状态为“已出租”，这两步必须作为一个事务整体提交，要么都成功、要么都失败，这个一致性保证就是 Spring 声明式事务在做。

• SpringMVC 是系统的“前台接待员”。它负责接收浏览器发来的 HTTP 请求，解析 URL、参数，然后把请求转给对应的 Controller 方法，处理完再返回视图或者 JSON 数据。简单理解：用户点了“新增商铺”，浏览器发了一个 POST 请求，SpringMVC 根据映射规则找到 Controller 里对应的处理方法，把表单数据绑定到 Java 对象上，业务处理完之后再通过视图解析器渲染 JSP 页面返回给用户。

• MyBatis 是系统的“数据搬运工”。它负责 Java 对象和数据库记录之间的转换。你在 XML 或者注解里写 SQL 语句，MyBatis 帮你执行并把结果集自动映射成 Java 实体类。比如你要查询所有“待出租”状态的商铺，写一条 SELECT 语句，MyBatis 把每个字段按映射规则塞进商铺对象里，再组装成一个 List 返回给 Service 层。

这个组合的精髓在于各司其职，每一层都知道自己该干什么。也正是因为职责边界清楚，你在写代码时思路也容易理顺：浏览器 → Controller（接参）→ Service（业务逻辑 + 事务）→ Mapper/DAO（数据库操作）→ 数据库。

2.2 为什么选 SSM 而不是 Spring Boot

可能会有同学问：现在新项目不都用 Spring Boot 吗？毕业设计为什么还要选 SSM，是不是有点过时？

我的观点是：SSM 作为毕设项目，不仅不过时，反而在“教学展示”这个维度上比 Spring Boot 更有优势。原因有三条：

第一，SSM 能体现你对框架底层原理的理解。Spring Boot 的核心关键词是“自动配置”，很多功能引入依赖之后直接就能用，这让开发变得很快，但在答辩的时候，一旦老师问“Spring Boot 的自动配置原理是什么”“你怎么配置数据源的”，答不上来就会很尴尬。SSM 不一样，它需要你手动配置 Spring 容器、配置 SpringMVC 的拦截器、配置 MyBatis 的 SqlSessionFactory、手动声明事务管理器。这些步骤看起来很繁琐，但每一步都在训练你对框架工作机制的理解。我见过太多用 Spring Boot 做得挺炫的同学被三连问直接问懵，反而是用 SSM 的同学能把配置代码讲得头头是道。

第二，SSM 可以和多个实用组件自然整合，论文内容更充实。在这个商铺租赁系统中，我们还要用到分页插件 PageHelper、JSR 303 参数校验、拦截器实现登录校验，这些框架层面的知识点放在 SSM 的背景下讲解，逻辑链条更顺。比如“拦截器在 SpringMVC 里的执行时机”这个问题，放在 Spring Boot 体系下讲反而有点绕，放在 SSM 里就非常直接。

第三，现在很多高校的课程和实训环节依然是 SSM 教学为主，完全贴合课堂教学进度。你做一个和课程知识高度匹配的项目，代码写起来顺手，遇到问题也容易找到资料，这在时间紧张的毕设季里是很现实的优势。

从个人经验来说，凡是以后打算走 Java 开发方向的同学，我的建议就是本科阶段认认真真做一个 SSM 项目，彻底理解配置和整合的底层逻辑；研究生阶段或者工作中再去拥抱 Spring Boot 全家桶。两头都不耽误，基础反而打得更牢。

2.3 系统总体架构的分层设计

这个系统采用的是典型的三层架构加 MVC 变体，从上到下可以分成四层：

• 表现层（Controller）：负责接收请求、参数校验、调用业务层、返回页面或数据。
• 业务层（Service）：负责具体业务规则的处理，比如“合同到期时间自动计算”“租金逾期判断”等；同时通过声明式事务保证数据库操作的原子性。
• 数据访问层（Mapper/DAO）：负责和 MySQL 交互，封装所有 SQL 操作。
• 数据库层（MySQL）：负责数据持久化存储。

除此之外还有两个横切关注点：日志记录和权限拦截。Spring AOP 可以用来统一记录关键操作日志，SpringMVC 拦截器用来做登录状态检查和角色权限判断。

我把这个架构图在心里过了一下，它就是一张非常规整的“请求流图”：用户发起请求，拦截器先拦住检查你是否登录，是管理员还是普通租客；然后 Controller 接收参数并调用 Service；Service 根据业务规则做判断，再调 Mapper；Mapper 执行 SQL 返回结果，结果一路向上返回，最终由视图解析器渲染成 JSP 页面呈现在用户面前。

这种设计的最大好处是“高内聚低耦合”。比如你要把 JSP 页面改成 Vue + 接口分离的形式，只需要改 Controller 的返回值，逻辑和数据库层基本不用动；又比如你想换一个数据库，只要改 MyBatis 配置里的连接信息，业务代码无需调整。对毕设来说，这种可扩展性既能在答辩时加分，也是工业界的主流规范。

3. 数据库设计：商铺租赁系统的“地基”

3.1 核心表结构规划与字段设计

数据库设计是这套系统最见功力的地方。业务功能再多，最后都落到表结构上。根据商铺租赁的业务流程，我建议规划六张核心表：管理员表、租户表、商铺表、租赁合同表、租金缴费记录表、公告表。下面把每张表的重点设计思路讲一下，方便你照着建表。

管理员表（admin）：字段不必多，主键 id、用户名、密码、真实姓名、创建时间即可。密码用 MD5 或 BCrypt 加密后存储，不要明文存库，这是最基本的底线，答辩时老师看到你用了加密存储，印象分会明显好一截。

租户表（tenant）：主键 id、租户姓名、手机号、身份证号、经营类型（餐饮、零售、服务等）、备注。身份证号在界面上要脱敏展示，细节虽然小，但能体现你考虑到了隐私问题。

商铺表（shop）：主键 id、商铺编号、所在楼层、门牌号、面积（平方米）、月租金单价、当前状态（待出租/已出租/已锁定）、描述信息。商铺状态字段建议用 tinyint 存数字（比如 0 待出租、1 已出租、2 锁定），不要直接存中文文本，这样查询效率更高、逻辑也更清晰。

租赁合同表（contract）：主键 id、合同编号、租户 id（外键）、商铺 id（外键）、起租日期、终止日期、月租金金额、押金金额、备注。这张表是整个系统的业务核心，也是报表统计的数据来源。

租金缴费记录表（payment_record）：主键 id、合同 id、缴费月份、应缴金额、实缴金额、缴费日期、缴费状态（未缴/已缴/逾期）、备注。这张表的设计直接决定了“租金台账”和“到期预警”功能好不好做。

公告表（notice）：主键 id、标题、内容、发布时间。

从关系上看，租户和商铺是多对多关系？不是的，实际上每份合同连接一个租户和一个商铺，也就是说一个租户可以租多个商铺（对应多条合同记录），一个商铺也可以在不同时间段租给不同租户（也对应多条合同记录）。所以“租户—商铺”之间通过合同表建立了一个多对多的关联。在逻辑判断时，要查询一个商铺是否处于“已出租”状态，本质上是检查是否存在一条状态正常且当前时间在起止日期之间的合同记录。

3.2 关键业务规则的数据库支撑

如果只是把表建出来，那还不叫设计，真正的难点在于如何用数据库支撑业务规则。

第一个要点是金额字段的类型选择。租金、押金这类金额字段，一定不能使用 float 或 double，否则会出现浮点精度误差，比如 100.5 存进去变成 100.4999999。正确做法是使用 DECIMAL(10,2)，10 位总长度、小数占 2 位，从根上避免精度问题。这是一个非常细节但特别容易踩坑的点，也是我常和同学强调的“成本最低的正确性保障”。

第二个要点是日期字段与“到期预警”功能的配合。合同起止日期建议用 DATE 类型，起租日期设计为 date，终止日期设计为 date，因为只需要精确到天。而租金缴费记录里的缴费日期，可以用 DATETIME 记录到时分秒，方便查看一天内的多笔操作。实现“30 天内到期”预警的 SQL 其实很简单：

SELECT c.contract_no, c.end_date, t.real_name, s.shop_no FROM contract c LEFT JOIN tenant t ON c.tenant_id = t.id LEFT JOIN shop s ON c.shop_id = s.id WHERE c.end_date BETWEEN CURDATE() AND DATE_ADD(CURDATE(), INTERVAL 30 DAY) AND c.status = 1;

这段 SQL 背后的逻辑是：我只需要在首页查询的时候带一个时间区间条件，就能把即将到期的合同筛选出来。如果在面试或答辩时被问到“预警功能怎么实现”，你不需要说自己用了复杂定时任务，直接讲清楚这个 SQL 的思路就足够了，但如果你想更进一步，也可以后面提 Quartz 定时任务或 Spring Task 定期扫描，给老师留一个优化空间。

第三个要点是唯一约束。商铺编号、合同编号必须有唯一性约束，防止重复录入。数据库层面的唯一索引是数据完整性的最后一道防线，设置了之后，就算代码出现并发 bug，也无法插入重复记录。

第四个要点是逻辑删除。毕设系统里可能会有人觉得“删除就是 DELETE”，但在真实企业项目里几乎都会用逻辑删除。建议在核心业务表里增加一个 status 或 del_flag 字段，删除时把值改成 1，查询时条件统一过滤掉。这样做的直接好处是：已产生的历史合同永远不会被物理抹掉，将来做数据统计时依然有据可查。

3.3 数据库初始化与测试数据

这一步很多人会忽略，但我强烈建议做。你辛辛苦苦把表建好，如果项目里一条数据都没有，演示的时候打开系统空荡荡的，观感极差，也不利于你测试分页、统计这类功能。

我会往表里插入模拟数据，比如 12 间商铺，分布在“一楼 A 区”“二楼 B 区”等等，给其中 8 间填上“已出租”并生成对应合同，合同中再选出 2 条设置为“30 天内到期”，再给 1 间商铺故意不填任何合同设置为“待出租”。这样无论是列表展示、详情查看、到期预警还是统计分析，都有真实的数据可以演示。

在创建项目文件时，我会专门放一个sql目录，里面包含三份文件：schema.sql（建表语句）、data.sql（测试数据）、README_SQL.md（数据库初始化操作说明）。把建表和初始化数据分开是很好的工程习惯，这个习惯放到简历上也能给你加印象分。

4. 功能模块拆解与核心实现方案

4.1 系统功能地图：管理员端与租户端

一个合格的商铺租赁管理系统，菜单结构大体应该长这样：

管理员端：

• 登录认证：账号密码校验、验证码、拦截器校验
• 商铺管理：新增商铺、编辑信息、修改状态、删除、分页查询
• 租户管理：新增租户、归档租户资料、按经营类型筛选
• 合同管理：签订合同、续签合同、到期合同列表、终止合同
• 租金管理：租金记录录入、缴费状态更新、逾期标识
• 统计分析：月度租金收入汇总、商铺出租率饼图
• 公告管理：发布公告、删除公告、公告列表展示

租户端：

• 查看已租商铺信息
• 查看自己的合同详情
• 查看缴费记录与下期应缴费用
• 查看平台公告

这里有一个隐藏的加分功能：管理员端首页的统计面板。用一个大的统计卡片展示“商铺总数、已出租数、待出租数、本月应收租金、近 30 天到期合同数”，开局一张清晰的数据总览，答辩时打开系统，第一印象直接拉满。我用过一个轻量级的统计 SQL，只需要几条聚合查询：

SELECT COUNT(*) FROM shop; -- 商铺总数 SELECT COUNT(*) FROM shop WHERE status = 1; -- 已出租 SELECT COUNT(*) FROM shop WHERE status = 0; -- 待出租 SELECT IFNULL(SUM(payable_amount), 0) FROM payment_record WHERE MONTH(pay_date) = MONTH(NOW()); -- 本月应收

4.2 登录认证与权限拦截的实现思路

登录认证是每一个后台管理系统的门面工程。在这个项目里，我不建议用一个简单的 Session 放用户名就完事，至少要包含这几个环节：

• 登录页校验图形验证码，防止暴力破解（用第三方 Kaptcha 组件即可）。
• 用户输入账号密码后，Service 层通过 MyBatis 查询数据库，比对加密后的密码。
• 登录成功后把用户信息存入 Session，方便拦截器取用。
• 定义 SpringMVC 拦截器，拦截所有/admin/**路径，判断 Session 是否为空。

拦截器的配置代码并不复杂，核心就是实现HandlerInterceptor接口：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("ADMIN_SESSION"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

这个拦截器是“一处配置，全局生效”的思想，如果你在 Controller 里每个方法都手动判断一下 Session 是否为空，代码就冗余严重了。关于角色权限，可以再定义一个角色字段区分管理员和租户，租户登录后只能访问/tenant/**路径下的资源，管理员不能访问租户端接口，反之亦然。

4.3 合同管理模块的时间冲突校验

说完登录再说业务模块，本着“先难后易”的原则，强烈建议优先写合同管理模块。这个模块里最核心的校验逻辑是“同一商铺在同一时间段内不能重复出租”。在签订合同之前，必须检查目标商铺在目标时间段是否已经存在冲突合同。

这个问题的本质是一个区间重叠判断，两段租赁时间 [start1, end1] 和 [start2, end2] 冲突的条件是：

start1 <= end2 AND start2 <= end1

翻译成 SQL 就是：

SELECT COUNT(*) FROM contract WHERE shop_id = #{shopId} AND status = 1 AND (#{startDate} <= end_date AND #{endDate} >= start_date);

如果查询结果大于 0，说明时间区间重叠，直接抛业务异常“该商铺在此时间段已有租赁合同”，不允许提交。这个逻辑看起来简单，但它是整个系统业务正确性的核心关卡，少了这一步你就会出现“一间商铺同时租给两个租户”的严重 bug，答辩时被问到时就是大漏洞。

合同履行的状态流转也要捋清楚：签订合同 → 生效中 → 到期自动结束 / 提前终止。建议在合同表加一个状态字段，0 生效中、1 已到期、2 已终止。在查询列表页时，根据当前日期动态判断合同的展示状态更为方便。

4.4 租金模块与统计报表的实现

租金记录表的字段设计我在前面已经讲了，在这一节重点说说实现逻辑。

租金保存的时机分两种思路：一种是在合同签订时，系统一次性自动生成租赁期内所有月份的缴费记录，状态全部为“未缴”；另一种是每个月人工录入一笔。毕设系统我建议用第一种，理由有两个：第一，它体现了自动化的价值，签完合同立刻生成未来 12 个月的缴费台账，这个效果在演示时非常漂亮，完全不用手动造数据；第二，这种设计能驱动后续“逾期未缴自动标红”的功能。

生成缴费记录的代码思路大概是：

public void generatePaymentRecords(Contract contract) { LocalDate start = contract.getStartDate(); LocalDate end = contract.getEndDate(); List<PaymentRecord> records = new ArrayList<>(); for (LocalDate month = start; !month.isAfter(end); month = month.plusMonths(1)) { PaymentRecord record = new PaymentRecord(); record.setContractId(contract.getId()); record.setPayMonth(YearMonth.from(month).toString()); record.setPayableAmount(contract.getMonthlyRent()); record.setStatus(0); // 未缴 records.add(record); } paymentRecordMapper.batchInsert(records); }

统计报表模块可以借助 ECharts 这种纯前端图表库，后端只需要提供统计数据接口，前端拿到数据渲染成柱状图或饼图。管理员首页展示“最近 6 个月租金收入趋势图”和“商铺出租率环形图”，答辩效果非常直观，而且 ECharts 的配置代码属于模板代码，写一次后面复制复用即可。

5. 开发过程中的常见问题与排查实录

5.1 SSM 整合阶段的高频报错

我带过的学生做这个项目，问题最多的地方往往不是业务逻辑，而是 SSM 框架整合阶段的环境配置。这里列几个高频问题和对应的排查思路，也是我每次帮别人调项目时必查的几个点。

第一个高频问题是Mapper 接口扫描不到，启动直接报Invalid bound statement。这个报错的本质是 MyBatis 没有把 Mapper 接口和 XML 映射文件绑定起来。排查顺序我记得烂熟：先看applicationContext.xml里的mapper-scan扫的包路径对不对，再看 Mapper 接口的包名和 XML 文件的namespace是否完全一致，三看 XML 文件里每个语句的id是否和接口的方法名相同，四看 Maven 构建时 XML 文件是否被过滤掉了（很多人忽略这个）。尤其是最后一点，如果 XML 放在src/main/java目录下，默认 Maven 构建不会把它打包进 classes，必须在pom.xml里配置：

<resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources>

第二个高频问题是Tomcat 启动时端口占用。8080 端口被其他进程占用的概率非常高，很多人不知道排查，只知道改 server.xml。实际上可以先在命令行用netstat -ano | findstr 8080找到占用 pid，再用任务管理器结束对应进程，或者直接在application.properties/yaml里换一个端口（比如 8081），速度最快。

第三个高频问题是数据库中文乱码。这个要从头到尾检查整个链路：数据库表字符集是否 UTF-8、JDBC 连接串是否带characterEncoding=utf-8、JSP 页面是否设置pageEncoding="UTF-8"、请求参数在 Tomcat 里是否按 UTF-8 解码。一个没设置就会乱码，而且乱码的根源不在它显示出来的那一端，而在源头，所以排查要从请求进来第一个环节开始看。

5.2 业务执行阶段的隐蔽 bug 集锦

框架阶段过了之后，业务功能的 bug 往往更隐蔽、也更考验人。

第一个隐蔽 bug 是金额精度问题。如果字段用了 double，即使数据库层面设了 DECIMAL，Java 端处理时的浮点运算依然会产生误差，尤其是累加统计的时候，最终结果可能差几分钱。处理口诀是：后端金额相关运算全部用BigDecimal，字符串构造器，不用浮点构造器。我在辅导代码的时候见到太多同学写得double total = amount + amount2，这种写法在金融业务里属于一票否决级别的错误，毕设虽然不会这么苛刻，但被老师指出来也很难看。

第二个隐蔽 bug 是分页查询时条件丢失。用 PageHelper 很容易出现一个问题：第一页带了“商铺名称模糊查询”条件，点第二页的时候条件参数没拼接在 URL 上，导致第二页显示的是全量数据。解决办法是分页跳转地址里显式携带查询参数，最好把查询条件封装成一个查询对象，每次请求都重新传入。这虽然是小细节，但从用户体验上看特别明显，也容易被演示时当场翻车。

第三个隐蔽 bug 是拦截器把静态资源拦掉了。不少人写了登录拦截器之后，发现 JSP 页面上的 CSS、JS、图片全部加载不出来，控制台一堆 404。原因是拦截器拦截路径写得过宽，把静态资源请求也拦截了。解决方案是在拦截器配置里排除静态资源路径：

<mvc:resources mapping="/static/**" location="/static/"/>

拦截器只拦截管理员相关的动态请求，静态资源一律放行。

5.3 排错方法论：从经验到工具

上面的问题，如果你自己去排查，我建议你掌握一套系统的排错手段，而不只是零散地报错百度。

第一，养成看日志的习惯。SSM 项目要把日志框架配置好，至少能看到 SQL 执行日志和异常堆栈。个人强烈建议配置 log4j2 或者 logback，日志级别开发阶段调成 DEBUG，能看到 MyBatis 执行的完整 SQL 和每个参数的值。项目在本地跑不起来了，第一步永远是打开控制台日志，从下往上找第一次出现的异常，而不是盯着最后几行看。

第二，学会用断点调试。很多人遇到问题就打印 System.out.println，这当然也可以，但我更推荐你在关键方法入口和判断分支上打几个断点，用 IDEA 的 Debug 模式跟一遍。尤其在查“为什么页面上没有显示数据”这种问题时，断点一看便知是 SQL 查出来就是空，还是 Controller 返回了但前端没渲染。

第三，SQL 先拿到数据库客户端里执行。任何 Mapper 的 SQL 出错，先别急着检查 XML 配置，而是把 SQL 拿进 Navicat 或者 MySQL 命令行里实际执行一下，看数据是否符合预期。SQL 本身没问题，再回头查参数映射和返回类型；SQL 本身有问题，直接在数据库端改好再拷贝回 XML。

6. 交付物清单与答辩准备建议

6.1 项目交付时应该包含哪些内容

做完项目不是终点，毕业设计的交付质量同样重要。按照常见的交付标准，这个项目至少应该提交这么几类东西：

• 项目源码工程，结构必须清晰，包名规范，类名见名知意，关键代码加上必要的注释。
• 数据库脚本（schema.sql + data.sql），能一键建库、一键导入测试数据，而不是让老师自己建表录数据。
• 项目运行说明文档（README），包括 JDK 版本、Maven 版本、Tomcat 版本、MySQL 版本、数据库账号密码、启动步骤。
• 毕业设计论文，按照学校提供的模板写，重点章节是系统设计、数据库设计、核心功能实现。
• 演示视频或 PPT，提前录制一个 5 分钟的完整操作演示，防止答辩现场网络或环境出问题。

很多人忽略前面两类交付物，只交一个源码压缩包，结果老师在自己的电脑上运行不起来，印象分直接打折扣。我强烈建议你按照“你是一个开源项目的维护者”的标准来组织交付物，能省去大量不必要的沟通成本。

6.2 论文结构建议与答辩加分技巧

论文的章节结构我写过很多次，这里给出一个比较标准的提纲，照着这个框架填充内容基本不会出大问题：

• 第一章 绪论：项目背景、国内外研究现状、研究意义、论文结构
• 第二章 相关技术介绍：SSM 框架、MySQL、JavaWeb、前端技术
• 第三章 系统分析：需求分析、角色分析、功能需求、非功能需求、可行性分析
• 第四章 系统设计：总体架构、功能模块设计、数据库设计
• 第五章 系统实现：核心功能模块的页面截图和关键代码说明
• 第六章 系统测试：测试用例设计、功能测试结果、性能测试简述
• 第七章 总结与展望

论文写作的时候有一个常见误区：把大段大段的源代码贴进论文里。这完全没有必要，论文里只需要放一段最核心的代码，然后在代码前后各写一段说明文字，解释这段代码实现了什么逻辑、解决了什么问题。老师想看的是你对设计的理解，而不是你的代码量。写 MyBatis 的 SQL 映射、写拦截器的实现逻辑这些关键模块，比贴一堆 CRUD 代码要高明得多。

答辩的时候记得准备几个项目的亮点，比如：使用了加密存储用户密码、设计了同一商铺时间冲突校验、实现了自动生成租金台账、通过 ECharts 展示统计图表、用拦截器完成登录权限控制。这些点每一个都能顺藤摸瓜讲出设计思路，是最容易获得老师认可的部分。

6.3 项目后续的可扩展方向

这个项目的代码完成后，即使毕业了，也可以继续往几个方向扩展，这些扩展点我也会在论文的“展望”部分写一点，显得你不是一个只会抄作业的工具人：

• 把 SSM 升级为 Spring Boot + MyBatis-Plus，减少大量 XML 配置，同时引入 Spring Security 做更细粒度的权限控制。
• 增加前端分离架构，把展示层替换为 Vue + Element UI，通过接口交互替代 JSP 页面渲染，为将来的微服务打基础。
• 加入消息提醒机制，当合同临近到期时，通过邮件或短信自动通知租户，这一步可以作为系统功能闭环的完善。
• 增加数据可视化大屏，把所有商铺的出租状态、收入趋势、到期分布放在大屏上一目了然展示，主要体现在前端展示能力。

这些方向你可以根据时间取舍，但如果能完成其中一到两个，整个项目的技术高度和答辩说服力会再上一个台阶。

最后分享一条我个人的经验：不要总想着把项目做到尽善尽美再开始写论文，而是每做完一个模块，就立刻把对应的截图和代码整理进论文草稿。我见过太多同学在 4 月份项目才做完，然后用十几天通宵赶论文，质量可想而知。正确的节奏是项目边做、论文边写，到四月下旬整体收尾，留出足够时间做演示文档、排练答辩。这个项目本身难度适中，只要按模块一步步推进，基本上三月中旬就能做出一个完整可运行的版本。

真正做完再回头看，你会发现自己对整条技术链路的理解，是和只看不练完全不一样的状态。