SSM房屋租赁管理系统：从设计到落地的全流程实战

做了好几年的Java后端，中间看过不少租房管理类的项目，自己也完整落地过两套类似的系统。今天想借这个机会，把基于SSM框架的房屋租赁管理系统从头到尾拆开讲一遍，包括功能怎么设计、表怎么建、代码怎么组织、哪些坑我是真金白银踩过的，全部整理出来。如果你正准备做毕业设计、课程设计，或者公司内部刚好要上一套租赁管理后台，这篇内容应该能帮你少走很多弯路。

先说下SSM框架是哪三件套：Spring、SpringMVC、MyBatis。这组合在中小型管理系统里非常能打，Spring管Bean和事务，SpringMVC管请求路由和参数绑定，MyBatis管数据库操作。相比现在流行的Spring Boot，SSM需要手动配置的东西多一些，但也正因为如此，很多底层的运作逻辑你会看得更清楚，对理解整个Java Web体系的帮助非常大。房屋租赁管理系统这种业务，本质上是围绕“房源—租客—合同—账单”四条主线做增删改查和状态流转，用SSM来写非常合适。

1. 系统整体设计与选型思路

1.1 为什么用SSM而不是其他技术栈

很多同学上来就问，现在都Spring Boot了，还用SSM是不是过时了？我的看法是，SSM对于特定场景依然有不可替代的价值。首先是学习价值，SSM的配置全部暴露在你面前，你可以看到DispatcherServlet怎么注册、Mapper怎么扫描、事务切面怎么生效，这些在Spring Boot里往往被自动配置藏起来了。如果你是学生或者刚转行的开发者，老老实实手写一遍SSM整合，你对Spring IoC、AOP、MyBatis动态代理的理解绝对会上一个台阶。

其次是项目环境的适配性，很多学校实验室、中小型公司的老项目，跑的就是SSM架构。你会SSM，意味着你能看懂存量代码，能做维护和二次开发，这在找工作时是个实打实的加分项。房屋租赁管理系统这种偏传统的信息管理类业务，对高并发、分布式没有刚需，反而更看重开发的稳定性和可维护性，SSM完全够用。

第三是部署成本，SSM打出来的War包丢到Tomcat里就能跑，一套JDK加一个Tomcat加一个MySQL就能撑起整个系统，不像微服务动辄要搞注册中心、配置中心。对于小团队运维来说，这种“简单直接”本身就是优点。

1.2 整体架构怎么分层

SSM项目最经典的分层方式是三层架构：表现层、业务层、持久层。表现层就是SpringMVC的Controller，负责接收HTTP请求、参数校验、调用业务接口、返回JSON或视图；业务层是Service接口加ServiceImpl实现类，承载核心业务逻辑，比如房源下架前要检查有没有未到期合同、租客退租时要自动结算账单；持久层是MyBatis的Mapper接口加XML文件，只做SQL交互，不掺业务。

这三层之外还需要两个横向模块。一个是公共工具层，放统一返回结果类、分页工具、字符串处理、日期处理这类通用方法；另一个是配置层，放Spring配置、SpringMVC配置、MyBatis配置、数据库连接池配置。我见过不少人把SQL直接写在Service里，或者把业务逻辑写在Controller里，短期的确省事，但项目一旦超过二三十个接口，这种写法会让你改一个需求牵扯出一堆隐藏Bug。严格分层，每一层各司其职，是SSM项目的第一纪律。

1.3 功能模块地图

一套完整的房屋租赁管理系统，至少需要覆盖以下模块。用户权限模块是基础的，管理员、业务员、财务员、租客这些角色各看各的菜单和按钮；房源管理模块管房屋的增删改查、上下架、户型、朝向、面积、租金定价这些基础档案；租客管理模块管租客的基本信息、身份证校验、历史租住记录；合同管理模块是整个系统的核心，涉及合同的创建、审核、签约、退租、续签全生命周期；账单管理模块负责租金、押金、水电费的生成、核销、催缴和统计；还有报修管理模块，记录报修工单从提交到处理完成的整个流程。这套模块划分同样适用于公寓管理、写字楼出租、车位租赁等场景，只是字段和流程细节略有差异。

2. 核心功能模块深度拆解

2.1 房源管理：状态机是灵魂

房源模块如果不做状态机，后面所有业务都会乱套。我推荐的房源状态至少有这几个：空置中、已预订、已出租、维修中、已下架。空置中可以转为已预订，已预订在租客签约后变为已出租，已出租在退租结算完成后回到空置中。维修中比较特殊，它可以由已出租或空置中进入，但维修完成后必须走审核流程确认房屋是否恢复可租状态。

数据库设计上，我建议在house表里加两个字段：一个是status，表示当前状态；另一个是previous_status，表示进入当前状态前的状态。为什么这么设计？因为你在实现“下架”功能时，需要知道房子是从空置中下架的，还是从已出租下架的，不同的前置状态对应不同的恢复逻辑。用previous_status记录现场，操作的时候不容易丢上下文。

实操心法：房源列表的筛选条件不要只按状态查，还要支持组合查询，比如“某个区域+某个租金区间+面积大于多少”。SQL不要用一堆if标签拼字符串，而是用MyBatis的 标签配合 做动态SQL。页码从1开始还是从0开始要前后端统一，我见过太多项目因为这个问题在联调时扯皮，建议直接约定pageNum从1开始，pageSize默认10，前端传参写死这个规则。

2.2 合同管理：全生命周期状态流转

合同是房屋租赁系统的重头戏，因为所有财务操作都围绕合同展开，合同状态一旦错了，账单就跟着错。合同的生命周期我建议拆成这几个状态：待审核、生效中、已到期、已退租、已作废。

重点说下审核环节，一份新合同创建后不能直接生效，需要业务主管审核租金单价是否低于最低限价、租期条款是否合理、押金是否足额。这个流程用一张独立的contract_audit表来记录更好，字段包括合同ID、审核人ID、审核结果、审核意见、审核时间。这样做的好处是后续查“为什么这个合同被拒”的时候有据可依，而不是只剩一条被修改过的状态。

合同创建时还有几个必须拦截的校验。第一个是同一房源不能存在两份生效中的合同，这个要用数据库唯一约束配合业务代码双重保证；第二个是租客如果在别的房源还有欠款，应该提示业务员先处理欠款；第三个是合同起止日期必须晚于系统当前时间，避免补录数据时产生不可控的时间交叉。

实操中很多人忽略的是合同编号生成规则，不要用自增ID当合同号，一旦数据迁移或分库，ID就乱了。建议用“HQ”前缀加年月日加当天序列号，比如HQ20250612001，生成逻辑放在Service层统一管理，用一个带行锁的sequence表来保证并发下不重复。

2.3 账单管理：自动生成与批量核销

账单模块最容易出Bug的是时间跨租期的问题。一份合同可能是2025年6月1日到2026年5月31日，按月起租，那么账单应该自动拆成12期，每期生成一条租金记录。生成逻辑我建议用定时任务每天扫描一次合同表，把处于生效中且当前日期恰好是账单生成日的合同批量生成账单，而不是在签约时一次性生成所有账单。为什么？因为中途可能调价、可能提前退租，一次性生成12条后面改起来非常痛苦。

账单字段一定要包含这几个：账单编号、合同ID、费用类型（租金/押金/水费/电费/物业费）、金额、起算日期、截止日期、状态（待支付/已支付/已核销/已退款）、关联支付流水号。其中支付流水号是线下转账场景中用来对账的关键，财务人员从网银导出的流水和系统里的记录做匹配时，全靠这个字段。

批量核销功能要支持两种方式：按合同核销和按租客核销。按合同核销适合租客一次性付清多期租金的情况，按租客核销适合处理一个租客名下多套房子的欠费。核销操作必须记录操作人ID和操作时间，后续财务审计时这笔数据的责任人是可追溯的。

2.4 权限管理：基于角色的访问控制

SSM项目里做权限管理最实用的方案就是RBAC，用户、角色、菜单三层关系。用户表存登录账号密码和状态，角色表存角色名称和标识符，菜单表存前端路由和按钮标识，中间再加用户角色关联表和角色菜单关联表。登录时把用户的所有权限标识塞进session或者放到ThreadLocal里，在SpringMVC的拦截器中校验每个请求所需权限。

我特别想提醒的是按钮权限。很多初学者只做菜单权限，觉得看不到入口就安全了，结果有心的用户直接推接口地址照样能访问。正确做法是后端每个接口都要校验操作权限，比如删除房源的操作需要“house:delete”这个权限标识。拦截器里加一个注解，比如@RequirePermission("house:delete")，通过HandlerInterceptor统一拦截，没有权限就返回403的JSON，前端再根据状态码隐藏按钮。这套机制看起来多写了一点代码，但安全性完全不一样。

数据库设计上用户名要做唯一索引，密码必须用BCrypt加密存储，SSM项目里集成一下jBCrypt库也就几行代码的事，千万不要用MD5，MD5彩虹表破解成本太低了。

3. 关键技术实现与踩坑实录

3.1 Spring与MyBatis整合的细节

SSM整合有个经典配置顺序，不能乱。先配Spring的数据源和事务管理，再配MyBatis的SqlSessionFactory，最后配SpringMVC的DispatcherServlet。其中有个经常出错的地方是mapper扫描，必须在Spring配置里加上<mybatis:scan base-package="com.example.mapper"/>，否则Mapper接口不会生成代理Bean，启动时直接报NoSuchBeanDefinitionException。

数据源我建议用Druid，不光是连接池，更重要的是它的监控页面能看SQL执行次数、慢查询、连接池活跃数，排查线上问题非常方便。Druid的配置里有几个参数值得注意：initialSize设置5，minIdle设置5，maxActive设置20，maxWait设置60000毫秒。这些值不是拍脑袋定的，单机Tomcat默认线程池200，数据库连接池开太大反而会增加连接切换开销，20个连接对租赁管理系统这个体量完全够用。

事务管理是SSM里最容易出问题的地方。开发阶段我建议把事务切面设为对Service包下所有方法生效，并且默认回滚异常类型要包含Exception而不仅仅是RuntimeException。Spring默认只对RuntimeException回滚，但你的业务里完全可能抛出自定义检查异常，不配置rollback-for会出现数据写了一半但事务没回滚的尴尬局面。

3.2 用MyBatis动态SQL处理复杂查询

房屋租赁管理系统的查询条件极其灵活，今天要按小区查，明天要按面积区间查，后天又要按租金排序。这些需求没必要每个写一个SQL，用MyBatis的 标签可以通吃。比如房源列表的查询可能是这样：

<select id="selectHousePage" resultType="com.example.entity.House"> SELECT * FROM house <where> <if test="houseName != null and houseName != ''"> AND house_name LIKE CONCAT('%', #{houseName}, '%') </if> <if test="minArea != null"> AND area &gt;= #{minArea} </if> <if test="maxRent != null"> AND rent &lt;= #{maxRent} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

注意到这里没有用${}拼接参数，而是全部用#{}防止SQL注入。LIMIT的offset需要提前在Service层计算好，(pageNum - 1) * pageSize。分页插件可以用PageHelper，用起来确实方便，但有个坑是PageHelper只对紧跟着的第一条查询语句生效，如果你在查询前做了一次查询或者调用了其他Mapper方法，分页就会失效甚至把SQL拼错。我的经验是使用PageHelper时，分页查询的Mapper方法里不要再前置查询任何其他东西。

联表查询是租赁系统里最常见的性能瓶颈。租客名、房间号、小区名分布在三张表里，有人直接用嵌套子查询，数据量一大就慢得离谱。更好的方案是建一张宽表或者使用JOIN加索引。比如查账单列表需要关联合同和房源，可以这样优化：

SELECT b.*, h.house_name, h.room_no, t.tenant_name FROM bill b JOIN contract c ON b.contract_id = c.id JOIN house h ON c.house_id = h.id JOIN tenant t ON c.tenant_id = t.id WHERE b.status = 'UNPAID' ORDER BY b.due_date ASC

这种多表JOIN查询，记得给外键列加上索引，否则数据量超过一万条就会开始卡顿。

3.3 拦截器实现登录与权限校验

SpringMVC的拦截器是SSM项目做登录校验的标准姿势。需要在SpringMVC配置里注册一个拦截器类，然后用 mvc:exclude-mapping 放行登录接口和静态资源。我的拦截器里会做三件事。第一，从请求头取token，没有token直接返回401；第二，根据token查Redis拿用户信息，查不到说明会话过期，返回401；第三，根据当前请求路径匹配权限标识，没有权限返回403。

有一个细节容易被忽略，就是拦截器里用HandlerMethod获取处理器方法上的注解。如果你用的是注解式权限方案，必须在拦截器里做这样的转换：

if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod = (HandlerMethod) handler; RequirePermission permission = handlerMethod.getMethodAnnotation(RequirePermission.class); if (permission != null) { // 校验当前用户是否拥有permission.value()对应的权限 } }

有些项目会把权限校验写在每个Controller方法内部，代码非常冗余，而且漏写一个方法就漏一个漏洞。集中在拦截器里做，逻辑统一也容易维护。

3.4 文件上传与图片处理

租赁系统里房东和中介肯定要传房源照片，这里有不少坑。第一是文件大小限制，SpringMVC的CommonsMultipartResolver需要配置maxUploadSize，如果你不配，默认只有1MB，传个稍微大点的实拍图就直接报错。我一般设为20MB，超过这个大小明显是异常上传。

第二是文件的存储方式，不建议直接存到数据库的BLOB字段，这样数据库会快速膨胀，备份和迁移都痛苦。更合理的做法是把文件保存到服务器的某个目录下，数据库只记录访问路径URL。如果考虑到后续多机部署，可以提前把存储方式抽象成接口，本地存储实现和云存储实现互换就方便了。

第三是图片访问的映射，在SpringMVC配置里需要加一个静态资源映射：

<mvc:resources mapping="/upload/**" location="/WEB-INF/upload/"/>

这里有个很多人踩过的坑，把文件存在WEB-INF目录下是安全的，因为用户不能直接访问，但你在浏览器预览图片的时候需要访问路径，所以必须加配置把这个目录映射出来。如果你把文件存webapp根目录下，那用户也可以直接访问，但安全性差一些，看你对图片的公开程度怎么取舍。

4. 系统部署与环境搭建指南

4.1 本地开发环境版本搭配

版本搭配是SSM项目新手最容易卡住的地方。我推荐一套经过了大量实践验证的版本组合：JDK 8、Maven 3.6.3、Tomcat 8.5或9.0、MySQL 5.7。Spring用5.1.x版本，SpringMVC同版本，MyBatis用3.5.x，MyBatis-Spring用2.0.x。这套组合在绝大多数系统上都能一次跑通，不会出现Spring 6要求JDK 17但你还在用JDK 8这种版本错位问题。

MySQL 5.7建议把默认字符集设为utf8mb4，这个很关键。utf8在MySQL里是utf8mb3的别名，存不了emoji表情和一些特殊字符，租房合同里甲方签字如果有特殊符号，很容易报错。utf8mb4是真正的完整版UTF-8，从建库那一天就设好，后面能省大量编码问题的排查时间。

4.2 Maven配置与依赖管理

用Maven管理SSM项目依赖是标准做法。但要注意，Spring 5.1和SpringMVC 5.1要求JDK 8+，如果你的Maven用的编译器级别是1.7，编译直接报错。pom.xml里一定要显式声明：

<properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>

依赖里最容易缺的是javax.servlet-api，这个在Tomcat运行时会由容器提供，但编译阶段必须声明为provided作用域。另一个容易漏的是jackson-databind，SpringMVC返回JSON依赖它把对象序列化成字符串，漏了会报406错误或返回一堆奇怪的对象字符串。

4.3 部署到服务器的步骤与脚本

打包部署这块我建议直接用Maven的package命令打出War包，然后丢到Tomcat的webapps目录。但在这之前有两处配置必须改成生产环境的值。第一处是数据库连接，jdbc.properties里localhost要改成真正的数据库服务器IP，密码不要用开发环境的弱密码，建议用Druid的config-filter对密码做加密。第二处是日志级别，开发时可以设成DEBUG，生产一定要调到INFO，否则日志文件一天能涨几个GB。

Tomcat启动时建议修改catalina.sh里的JAVA_OPTS，把堆内存调大：

JAVA_OPTS="-Xms512m -Xmx1024m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m"

房屋租赁系统用CMS垃圾回收器就很合适，响应时间优先，吞吐量也能接受。连接数方面，如果预估在线管理员和租客同时在几百人左右，Tomcat的maxThreads保持默认的200就够了，不需要刻意调高。

如果公司有内网穿透需求，可以用Nginx做反向代理，把80端口转发到Tomcat的8080端口，顺便把/uploads的静态文件请求直接代理到目标目录，这样Tomcat的压力能小很多。Nginx的配置大致是这样的：

server { listen 80; server_name yourdomain.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /home/www/upload/; } }

5. 常见问题与排错经验

5.1 问题速查表

我把开发SSM租赁系统时最常见的几个问题整理成一张表，每个问题都是我或身边同事真实碰到过的，解决方案也是实测有效的。

5.2 必然遇到的N+1查询问题

N+1问题具体表现是：查了N条主数据之后，每条主数据又单独触发一次SQL去查关联数据。比如账单列表页查出100条账单，每条账单都实时去查一次合同和租客信息，那总共要执行1加100次SQL。一开始数据量小看着没事，到了月中账单高峰就明显卡顿。

解决方案就是在Mapper的查询里一次性JOIN出需要的关联字段，或者用MyBatis的collection标签做嵌套结果映射。数据量大时还有一种思路是加缓存，把房源的基础信息缓存到Redis，账单查询时优先从缓存拿。但缓存只适合读多写少的数据，房源状态这种频繁变化的数据不建议缓存过久，最多5分钟过期。

5.3 合同日期与账单日期边界如何避免混乱

合同起止日期计算有个经典错误，很多人用当前时间加30天来算下一期账单，这会导致每个月账单日期漂移。正确做法是根据合同里固定的起租日，比如每月5日为账单生成日，到了5日自动生成当月1日到月末的费用。这样处理跨月比较清晰：租客1月15日入住，首期账单是从1月15日到1月31日，第二期是2月1日到2月28日，不会出现重复计费或漏计费。

具体实现可以用一个定时任务，每天早上10点扫描contract表的生效合同，用SQL计算每个合同当前期次和结束日期。SQL可以用DATE_FORMAT和DAY来判断当天是否为账单日，也可以用Java的LocalDate计算后批量插入。我个人的经验是，定时任务里的时间对比统一用数据库服务器时间，不要用应用服务器时间，否则两台服务器的时钟有偏差，账单生成就会错位。

5.4 数据迁移与备份注意点

这种管理系统跑了一两年后，表里的历史数据会很多，动辄几十万条账单记录。数据库备份尽量用mysqldump在凌晨低峰期进行，备份的时候用--single-transaction参数，避免锁表影响业务。恢复的时候先用一个小脚本检查备份文件完整性，不然恢复到一半发现文件损坏是非常糟糕的体验。

如果要做数据归档，我的建议是把三年前已完结的合同和账单迁移到history开头的归档表，原表保留最近三年的热数据。查询历史记录时，如果当前表查不到，再加一条SQL查归档表，应用层对调用方透明。这样既能保证列表页查询速度，又不丢失任何历史数据。

6. 后续扩展与二次开发建议

6.1 从SSM平滑迁移到Spring Boot

如果你的SSM项目已经稳定运行，但团队想逐步往Spring Boot迁移，不要重写，用增量迁移的思路。新建一个Spring Boot工程，先把公共配置和工具类复制过去，然后把Mapper接口和XML文件原封不动搬过来，再把Service层按依赖顺序逐个搬运。Controller层的迁移最容易出错的地方是返回类型和路径映射，建议搬一个模块就整套联调一遍。

Spring Boot的starter确实省了很多配置，但SSM时代手动配置积累的排错经验依然有效。理解了SSM的每个配置项在做什么，当你用Spring Boot时即使遇到自动配置不生效也能很快定位问题，因为你知道它底层本质上是什么机制在工作。

6.2 移动端与消息通知扩展方向

租赁管理系统做完Web版之后，最常见的扩展方向是给租客做一个H5或微信小程序端。思路是复用现有Mapper和Service，单独写一套移动端Controller，返回JSON给前端。这块要注意的是权限模型要有区分端口的能力，比如Web管理员端能看到退租审核按钮，租客端只能看到自己的合同和账单。一种做法是在权限表加一个platform字段，同一接口不同平台返回不同菜单树。

消息提醒也值得加，到期提醒、账单逾期提醒、报修进度提醒都可以通过接入短信或微信模板消息推送。实现上不要直接在业务代码里循环发短信，建议把提醒事件写入一张message_task表，由定时任务扫描批量发送，这样就算消息通道临时故障，任务还可以重试，不会把业务线程阻塞住。

6.3 项目文档与交接的沉淀

最后提一个很多人忽视的方面，就是项目文档。SSM项目不像Spring Boot那样靠注解就能猜出大半逻辑，很多配置分散在XML里，不写清楚后人接手会非常痛苦。我给自己定的规矩是每个模块至少写一页说明文档，包含：表结构说明、关键接口清单、核心流程的状态流转图（用文字描述）、部署步骤、常见问题。这两年的实践证明，这份文档节省的排查时间远远超过写它花的时间。

写在最后的体会

做房屋租赁管理系统这类业务，最大的难点从来不是技术有多深，而是业务规则足够琐碎。合同有生效期、账单有起止日期、房源有状态约束，任何一点没考虑周全，上线后就会被用户骂。我个人最大的感受是：先把核心业务流程画清楚，确认每个状态怎么流转、每个操作触发什么后续动作，再动手写代码。代码本身反而不是最大的工作量，梳理业务逻辑才是。

如果你现在正准备动手做这套系统，我的建议是先从房源和合同这两个模块入手，把核心链路跑通，再补账单和权限。不要一上来就想把所有功能做完，那样很可能连表结构都设计得互相矛盾。每完成一个模块，用真实数据走一遍全流程，你会发现很多设计层面的漏洞都是这样查出来的。这个项目做完，你至少能摸透SSM的整合、复杂动态SQL的编写、事务边界的划分这几项硬技能，对后续不管是继续做Java还是转其他方向，都是实打实的积累。