做管理系统这件事平时觉得不难真正动手之后才发现细节全在业务逻辑里。房屋租赁管理系统听起来就是个CRUD但你要是真去理一遍需求会发现房东、租客、合同、账单、房源状态这几个东西搅在一起复杂度远超预期。这篇东西我就结合自己做过的项目从一个SSM框架的房屋租赁管理系统出发把功能设计、表结构思路、核心实现和踩坑记录完整梳理一遍给准备做类似系统的朋友一个可参考的底子。1. 整体设计思路与需求拆解1.1 为什么选SSM框架来承接租赁系统SSM是Spring SpringMVC MyBatis的组合在中小型管理系统中属于非常成熟的技术栈。房屋租赁管理系统这类业务特点是实体关系多、表单操作密集、权限角色分明但不涉及超高并发和复杂分布式场景SSM正好能稳稳接住。Spring负责对象管理和事务控制SpringMVC处理请求路由和参数封装MyBatis负责SQL与Java对象的映射。这三层各司其职让代码结构足够清晰。相比Spring BootSSM的优势在于配置透明、依赖可控对学习框架底层原理很有帮助劣势是配置繁琐但用熟了之后会发现这种“麻烦”反而让人对运行机制理解得更透彻。我做这个系统时Java版本用的JDK 1.8框架版本Spring 5.1.x、MyBatis 3.4.x数据库用的MySQL 5.7。连接池用的Druid既能监控SQL性能又能防SQL注入这类管理系统的数据库交互频繁连接池选型值得认真对待。1.2 租赁业务的角色边界与权限模型租赁系统最核心的不是房源而是“谁在什么时间对哪间房做了什么”。所以第一件事就是把角色拆清楚。本系统设计了三个角色管理员平台运营方负责房源信息维护、所有合同审核、账单管理、数据统计。房东房源的实际拥有者可以发布房源、查看名下合同与收益。租客承租人可以浏览房源、发起租赁申请、查看个人合同与缴费记录。这个模型对应的权限控制是管理员拥有全部菜单权限房东只能操作自己名下的房源和合同租客只能查看与处理与自己相关的申请、合同和账单。SpringMVC拦截器基于Session中保存的用户角色做URL级别的拦截菜单渲染时也按角色动态生成。注意权限校验必须在后端做前端隐藏按钮只是体验优化真正拦截靠拦截器和SQL层面的数据归属过滤。比如房东查询合同列表时SQL里必须带landlord_id 当前用户id不能只靠前端传参。1.3 核心业务流程梳理系统的核心链路可以归纳为一条主线房源录入 - 租客申请 - 合同签订 - 账单生成 - 租金收缴 - 退租退房。围绕这条主线周边还有用户管理、房源类别管理、统计报表等支撑模块。我画业务流程图时第一步先把这条主线画清楚再往里面补分支比如合同续签、逾期催缴、房源下架刷新等。这条主线的核心逻辑在于状态流转房源状态空置 - 待审核被申请 - 已出租 - 已下架合同状态待生效 - 生效中 - 已到期 - 已解约账单状态待缴费 - 已缴费 - 已逾期 - 已退款每一个状态变化都对应一个具体的业务动作比如合同生效时房源状态同步改为已出租合同到期时账单停止生成本期费用退租解约时释放房源并结算押金。这些联动在代码实现时最容易漏后面我会专门讲。2. 数据库表结构设计与核心实体关系2.1 表设计原则与ER关系房屋租赁管理系统的表设计要满足两个基本原则状态可追溯和数据可对账。可追溯意味着每一次合同变更、房源状态变化都要有记录可对账意味着每一笔押金、每一期租金都能从账单表逆行查回合同与租客。我的数据库一共设计了8张核心表表名用途关键字段user用户表三种角色统一存放id, username, password, role, phonehouse房源表id, landlord_id, title, address, area, price, statushouse_image房源图片表id, house_id, image_url, sortlease_contract租赁合同表id, contract_no, house_id, tenant_id, start_date, end_date, deposit, rent, statusrent_bill账单表id, contract_id, bill_month, amount, status, pay_timemessage站内消息表id, sender_id, receiver_id, content, is_readoperation_log操作日志表id, user_id, action, detail, create_timehouse_apply租房申请表id, house_id, tenant_id, status, apply_time从ER关系来看user与house是一对多一个房东可以有多套房源house与lease_contract是一对多一套房源在不同时间有多份合同但同一时间只有一份生效合同lease_contract与rent_bill是一对多一份合同生成多期账单house_apply关联租客与房源形成申请记录。这里有个容易犯的错合同跟房源的关系不能设计成一对一。房源退租后重新出租会生成第二份合同所以必须是一对多查询时通过status 生效中取当前有效合同。2.2 合同表与账单表的账务闭环合同表是整个系统的账务枢纽。上线前我反复算过账单的生成逻辑最后定下的规则是租金单价写入合同表快照不实时取房源表的price避免后续房东改价导致历史账单数据错乱。账单按月生成每月1号定时任务扫描生效中的合同自动生成当月账单金额 合同租金单价 × 房屋面积或按月固定金额。首月账单比较特殊如果签约日是月中则首月按实际天数折算后续月份才走整月固定金额。押金单独记录在合同表deposit字段中不参与账单生成退租时走退款流程。这个设计背后的原因是房源价格可能变动但合同一旦签了租金在合同期内就必须保持稳定。数据快照是管理系统中非常实用的手段很多新手容易忽略。2.3 索引设计与数据查询优化系统运行一段时间后数据量会集中在lease_contract和rent_bill两张表上。我在设计索引时重点考虑了以下几个查询场景场景一租客查自己名下的有效合同高频SQL是SELECT * FROM lease_contract WHERE tenant_id ? AND status 生效中所以建了(tenant_id, status)联合索引。场景二管理员按月统计账单回款情况高频SQL是SELECT ... FROM rent_bill WHERE bill_month ?建了bill_month单列索引。场景三房东查名下所有房源SELECT * FROM house WHERE landlord_id ?建了landlord_id索引。提示MySQL 5.7里要留意索引失效的情况比如对索引字段做了函数运算、隐式类型转换或者LIKE %xxx前置模糊匹配都会导致索引失效。我排查慢SQL时第一步就是EXPLAIN看执行计划确认key字段是否真正命中了索引。3. 系统功能模块拆解与实现要点3.1 用户登录与权限拦截登录逻辑不复杂但有几个细节值得说。用户表里密码存储用的是MD5(password salt)加盐方式虽然现在更推荐BCrypt但SSM项目里用这个组合也说得过去。盐值在注册时随机生成存到user表的salt字段中。校验登录时先按username查出user再计算MD5后比对而不是直接WHERE username? AND password?这样后续想要升级加密算法或者做密码重置改动成本都小。权限拦截我实现了一个LoginInterceptor和一个AdminInterceptor。LoginInterceptor拦截所有非静态资源路径检查Session中是否有loginUserAdminInterceptor在此基础上再检查role是否为管理员。房东和租客的权限区分通过菜单渲染控制后端URL只区分“登录用户”和“管理员”两个级别具体的数据范围控制在Service层里做。这里要提醒一个实际经验Session超时之后用户点击提交按钮会跳转到登录页但之前填的表单数据全部丢失。我在前端加了一个全局的Ajax错误拦截当响应码是401或跳转地址指向登录页时弹窗提醒用户重新登录而不是静默刷新页面。3.2 房源管理从发布到下架的全状态流转房源管理的功能表面上是增删改查实际上核心是状态机。房东发布房源时状态为空置此时租客可以在前台搜索到这套房并提交租房申请。管理员可以在后台对房源进行审核如果房源信息不完整或者价格异常可以驳回让房东修改。审核通过后房源正式对租客可见。租客提交申请后房源状态变为待出租仍然可以展示但申请按钮置灰。合同签订成功后房源状态变为已出租。租客退租、合同状态变为已到期房源状态自动恢复为空置。我用一个状态常量类来管理这些状态值public class HouseStatus { public static final Integer EMPTY 0; // 空置 public static final Integer PENDING 1; // 待审核 public static final Integer RENTED 2; // 已出租 public static final Integer OFF_SHELF 3; // 已下架 }房源列表查询支持按区域、价格区间、面积区间和出租状态筛选。价格筛选的SQL实现上用MyBatis的if标签动态拼接条件避免写死SQL。图片上传用的本地存储图片路径存到house_image表展示时按sort字段排序取第一张作为封面。3.3 租房申请流程状态驱动的双向确认租房申请不是简单的“提交-通过”我设计了双向确认机制租客提交申请 - 申请状态为待处理房东可以同意或拒绝 - 同意后状态变为待签约租客确认签约 - 系统根据房源和申请信息生成合同草稿 - 状态变为待支付押金租客支付押金 - 合同生效 - 状态变为已完成这套流程的核心价值在于房源不会被一个未确定的申请锁死。申请被同意但在租客确认签约之前房东如果收到另一个租客的申请系统仍然允许发起沟通只是会提醒已有待签约申请。实际做的时候为了防止房源被重复签约我在数据库层面加了一个约束某个房源同一时间最多只能有一份状态为生效中的合同。house_apply表里的status字段完整记录了这个状态流转。对应到代码实现上每次状态变更都通过Service层的applyService.changeStatus(applyId, targetStatus)方法统一处理方法内部会校验前置状态是否合法不合法直接抛异常。3.4 合同管理签约、续租、退租与押金结算合同管理是功能最密集的模块。合同核心操作包括创建合同根据房源信息和租客信息生成合同编号编号规则我定的是HT 年份 月份 随机四位保证可读性且不重复。合同生效押金支付完成后合同状态从待生效变为生效中同步更新房源状态为已出租。合同到期定时任务每天扫描合同表把结束日期小于当前日期且状态为生效中的合同批量更新为已到期同时把关联房源状态改为空置。合同解约提前退租管理员录入解约原因和实际退租日期系统计算违约金按合同约定比例这里我默认设置为一个月租金的10%从押金中扣除后剩余押金原路退回租客。账单计算到退租当月为止。这里有个关键的日期边界问题租客在当月25号退租那当月租金怎么算我在项目中定了一套规则合同中有个字段settlement_date记录退租结算日退租当月账单金额按实际居住天数折算已经整月生成的账单通过负数调整单来冲销。为了在账单表里区分费用类型rent_bill增加了bill_type字段1为正常租金2为违约金3为退款调整单。3.5 账单管理自动生成、逾期催缴与收款核销账单模块的逻辑决定了财务数据是否准确。我用的方案是账单由定时任务按月生成而不是租客点击“去缴费”时才生成。这样做有几个好处账期清晰每月账单都有固定的bill_month标识方便对账。逾期统计可以直接基于账单表做不需要额外维护逾期状态。管理员后台的应收实收报表可以直接按账单表聚合。生成逻辑用Spring的Scheduled定时任务实现每月1日凌晨1点执行Component public class RentBillSchedule { Autowired private LeaseContractMapper contractMapper; Autowired private RentBillMapper billMapper; Scheduled(cron 0 0 1 1 * ?) public void generateMonthlyBill() { ListLeaseContract activeContracts contractMapper.listActiveContracts(); for (LeaseContract c : activeContracts) { RentBill bill new RentBill(); bill.setContractId(c.getId()); bill.setBillMonth(DateUtil.formatMonth(new Date())); bill.setAmount(c.getMonthlyRent()); bill.setStatus(BillStatus.UNPAID); bill.setCreateTime(new Date()); billMapper.insert(bill); } } }租客缴费后账单状态变为已缴费记录pay_time。如果同一个账单被重复支付比如租客连点了两次我在bill表加了唯一约束(contract_id, bill_month, bill_type)第二单插入时兜底捕获异常并提示“该账单已缴费”。3.6 数据统计出租率、租金回款率与趋势图表统计页面是给管理员和房东看的核心指标有三个出租率 已出租房源数 / 总房源数 × 100%剔除已下架房源。租金回款率 指定月份已缴费总金额 / 该月应收总金额 × 100%。租金趋势 按月展示应收金额、实收金额和逾期金额用折线图呈现。实现方式用一个专门的StatisticsControllerSQL层通过聚合查询直接返回前端需要的JSON结构。比如趋势图的数据就查SELECT bill_month, SUM(amount) FROM rent_bill GROUP BY bill_month前端用ECharts渲染。统计口径有一个坑要注意退租月份的账单如果做了负数调整单聚合SQL不能直接sum否则会把退款金额当负收入冲销。我最终的做法是统计时仅统计bill_type1且status已缴费的账单退款金额单独在退款统计中展示账目才清楚。4. SSM框架核心技术点与实战配置4.1 SpringMVC请求流转与参数封装SSM项目的请求链路是Tomcat接收请求 - DispatcherServlet - HandlerMapping匹配Controller - Controller处理 - Service - Mapper - 返回JSON或视图。我在Controller层统一返回Result对象code、message、data配合ResponseBody输出JSON。前端所有Ajax请求都走这个统一格式前端根据code判断成功与失败弹窗提示message这样比直接返回裸JSON或字符串好用得多。参数封装方面列表查询统一用一个QueryObject类接收前端传来的查询参数包含page、limit、keyword、sort等字段。分页用的是PageHelper插件在业务代码中不用手写limit和count只需要在查询前调用PageHelper.startPage(pageNum, pageSize)后面紧跟的查询会自动执行count并分页。注意PageHelper的分页原理是拦截器修改SQL拼上limit所以startPage和第一个查询之间不能有任何其他SQL操作否则分页会失效且难以排查。4.2 MyBatis动态SQL与多条件组合查询租赁系统的查询条件组合非常灵活房源列表、账单列表、合同列表都面临多条件筛选。MyBatis的动态SQL在这种场景下是利器。以房源列表查询为例where标签和if标签配合可以在参数为空时自动跳过条件select idqueryHouseList resultTypeHouse SELECT * FROM house where if teststatus ! null AND status #{status} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if if testkeyword ! null and keyword ! AND title LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY create_time DESC /select这里要注意LIKE查询的性能问题。房源表的keyword搜索如果数据量超过几万条%keyword%的前置模糊匹配会导致索引失效。我在项目里做了折中标题字段允许模糊但至少输入2个字才触发搜索同时把搜索范围限定在当前租客可见的房源上保证体验基本够用。4.3 Spring事务管理与跨方法调用的问题合同签约流程涉及多张表的原子性操作更新合同状态、更新房源状态、生成首期账单、记录操作日志。任何一个环节失败前面的操作必须回滚。我在Service层用Transactional(rollbackFor Exception.class)标注核心方法Transactional(rollbackFor Exception.class) public void signContract(ContractSignDTO dto) { contractMapper.updateStatus(dto.getContractId(), ContractStatus.EFFECTIVE); houseMapper.updateStatus(dto.getHouseId(), HouseStatus.RENTED); billMapper.insertFirstMonthBill(dto.getContractId()); logMapper.insert(OperationLog.create(签约, dto.getContractId())); }这里有一个Spring事务的经典坑同类内部方法调用时事务注解不生效。比如SignService里有个public方法a调用了同类中的public方法bb上标了Transactional但b不会进入代理对象事务不会开启。我排查这个问题时花了不少时间最后把需要事务的公共方法都拆到独立的Service类中或者直接在方法a上加事务保证事务边界正确。4.4 Druid连接池与慢SQL监控配置Druid在SSM项目中承担的不只是连接池职责它的StatFilter和WallFilter可以统计SQL执行时间、拦截SQL注入。我在applicationContext.xml中配置了Druid数据源bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName valuecom.mysql.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/house_rent?useUnicodetrueamp;characterEncodingutf8/ property nameusername valueroot/ property namepassword value123456/ property nameinitialSize value5/ property nameminIdle value5/ property namemaxActive value20/ property namemaxWait value60000/ property namevalidationQuery valueSELECT 1/ property nametestWhileIdle valuetrue/ /bean关键参数的含义initialSize是启动时初始化的物理连接数maxActive是最大连接数maxWait是获取连接的最大等待时间毫秒超过会抛异常。testWhileIdle设为true后Druid会在空闲连接回收时检查连接是否有效避免数据库重启后连接池还拿着死连接。Druid的监控页面我在生产环境并没有对外开放只看本地日志。通过配置StatFilter慢SQL会记录到druid-slow.log中我在排查报表接口响应慢的问题时就是从这里发现账单聚合查询没有走索引的。5. 前端页面与交互设计实录5.1 页面架构与技术选型前端没有用复杂的框架就是JSP Bootstrap jQuery ECharts。之所以选择这个组合而不是前后端分离的Vue是因为SSM项目用JSP可以直接通过EL表达式读取后端数据降低了页面渲染的复杂度而且部署时不需要额外的静态资源服务器。整体页面布局采用经典的左侧菜单 右侧内容区结构。左侧菜单根据角色动态渲染管理员看到的是完整菜单房东看到的是房源管理和合同管理租客看到的是房源浏览和我的租房。菜单渲染在后端Controller中把用户的权限菜单列表放进ModelJSP中循环输出。5.2 表格与表单的关键交互细节列表页基本都用Bootstrap Table组件服务端分页模式。前端初始化表格时传入url后端返回的JSON结构是{total: 100, rows: [...]}Bootstrap Table会自动处理分页渲染。表单提交我统一用jQuery的ajax方式拿到Result对象后判断code。这里有一个体验细节提交按钮在请求发出后立即置为禁用状态等响应回来后再恢复防止用户重复点击导致重复提交。这个在账单缴费和签约流程中尤其重要。删除操作没有用原生confirm而是自定义了一个模态框二次确认后再调删除接口。房源删除前会先校验是否有关联的生效合同如果有拒绝删除并提示“该房源存在生效合同无法删除”。5.3 数据可视化的报表展示统计页面用ECharts展示主要有折线图和饼图。折线图展示近6个月的租金趋势应收、实收、逾期三条线饼图展示当前房源状态的分布比例。数据由后端聚合接口以JSON格式返回前端setOption渲染。这里有一个前端细节图表容器初始化时如果没有数据ECharts会显示空白但不会报错。我在渲染前判断data是否为空为空时显示一张“暂无数据”的占位图避免管理员看到空白页面心慌。6. 部署发布与环境配置6.1 本地开发环境搭建开发环境我用的是IntelliJ IDEA配置了Lombok插件减少实体类getter/setter代码Tomcat 8.5MySQL 5.7Maven 3.6Maven管理依赖核心依赖有spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid、jstl、jackson-databind、pagehelper等。项目结构按Maven标准划分controller、service、mapper、entity、dto、util、interceptor等包。资源目录下放mapper的XML文件通过mybatis-spring的mapperLocations配置指定扫描路径这样XML和接口就能自动关联。6.2 Linux服务器部署步骤部署到Linux服务器的步骤我整理成了一套顺手流程打包在项目根目录执行mvn clean package -Dmaven.test.skiptrue生成的war包在target目录下。上传用scp把war包传到Linux服务器的/opt/tomcat/webapps目录。配置修改Tomcat连接池、JVM参数和MySQL连接信息重启Tomcat。初始化数据库执行建库SQL脚本和初始化数据脚本创建管理员账号。验证访问登录页用管理员账号登录检查各功能模块。这一步有一个经常踩的坑Linux下MySQL的大小写敏感问题。表名和字段名在Windows下开发时大小写混用可能没问题但Linux下MySQL配置了lower_case_table_names0时表名大小写就敏感了。我统一了规范数据库对象全部用小写加下划线命名从根源上解决。6.3 备份与定时任务维护数据库备份我写了一个shell脚本每天凌晨3点用mysqldump备份数据库到指定目录保留最近30天的备份文件#!/bin/bash BACKUP_DIR/data/backup/mysql DATE$(date %Y%m%d%H%M) DB_NAMEhouse_rent mysqldump -uroot -p123456 $DB_NAME $BACKUP_DIR/${DB_NAME}_${DATE}.sql find $BACKUP_DIR -name *.sql -mtime 30 -exec rm -f {} \;配合crontab每天执行一次。即使系统规模小备份不能省。我之前遇到过一次数据库误删数据的情况没有备份就只能干瞪眼恢复数据全靠手动补录痛苦程度不想再经历第二次。7. 常见问题与排查技巧实录7.1 中文乱码问题的完整排查路径中文乱码是SSM项目里出现频率最高的问题可能出现在请求参数、数据库存储、JSON响应三个环节。我在搭建项目时一次性解决了这三个环节页面编码JSP页面顶部设置pageEncodingUTF-8。请求编码SpringMVC的CharacterEncodingFilter强制编码UTF-8注意这个Filter必须配置在web.xml所有Filter最前面。数据库连接JDBC URL加characterEncodingutf8参数。数据库表建表时指定DEFAULT CHARSETutf8mb4这比utf8更保险能存emoji和生僻字。排查顺序建议是先看数据库里存的什么再看HTTP响应头里的Content-Type再看浏览器实际渲染编码。通常是数据库连接或Filter配置缺失的问题。7.2 事务不生效的深层原因与解决方案前面提到内部方法调用导致事务不生效之外还有两种情况值得注意第一种是异常被吞掉。Transactional默认在RuntimeException时回滚但如果你在业务代码中catch了异常没有往外抛事务框架根本感知不到异常也就不会回滚。我在签约流程中保证异常必然向上抛出统一由Controller层捕获。第二种是事务管理器没有配置。只加Transactional注解但Spring容器中没有配置DataSourceTransactionManager事务同样不会生效。记得在applicationContext.xml中注册bean idtransactionManager classorg.springframework.jdbc.datasource.DataSourceTransactionManager property namedataSource refdataSource/ /bean7.3 慢查询排查与SQL优化实例系统上线初期管理员打开账单管理页面要等3秒多我排查后定位到问题在账单列表的关联查询上。原本的SQL把contract表和house表都join进来再加WHERE条件导致数据量大了之后查询很慢。优化思路是减少不必要的关联。账单列表页其实只需要显示合同编号、房源标题和租客姓名这三个信息可以通过字段冗余解决。我在rent_bill表中增加了contract_no、house_title、tenant_name三个冗余字段在账单生成时写入这样列表查询只需要查rent_bill单表不需要join任何其他表。归档后查询速度从3秒降到200毫秒以内。心得小项目不要迷信三范式。读多写少的报表类查询适度冗余字段性能收益是立竿见影的。如果你也在做类似的租赁管理项目报表页的join数量尽量控制在1到2个以内。7.4 定时任务重复执行问题定时任务偶尔会重复执行比如同一月份的账单生成两份。原因有两个一是服务器部署了多个实例比如测试环境重启了多次Spring容器重复初始化二是Scheduled没有分布式锁。对于单服务器部署的SSM项目我用了最简单的方案在任务执行时查数据库判断目标月份账单是否已存在存在就跳过。这样即使任务跑了两次数据也不会重复。代码上就是在遍历合同时先SELECT COUNT(*) FROM rent_bill WHERE contract_id? AND bill_month?大于0则continue。8. 经验总结与后续扩展方向到这里这套SSM房屋租赁管理系统的设计和实现都梳理完了。回过头来看SSM框架虽然“老”但用它做管理系统得到的架构认知是不过时的。把Spring的IOC/AOP、MyBatis的SQL控制力、SpringMVC的请求链路摸透之后再去看Spring Boot的原理很多东西都是一通百通。我个人在实际开发中的体会是租赁管理系统的难点从来不在技术而在业务边界。每设计一个功能都要先问清楚“状态从哪来、到哪去、变化时还有谁需要知道”。把这几个问题想透了代码写起来会非常顺后期的bug也少。最后再分享一个小技巧合同编号和账单编号这类业务编号生成时一定要包含时间戳元素。我见过一些项目用数据库自增id直接当业务编号一旦数据迁移或分库编号混乱的问题会让你怀疑人生。如果后续项目要继续扩展我会优先考虑三个方向一是引入Spring Security或Shiro替换手写拦截器把权限模型升级为RBAC加数据权限双层控制二是把本地图片存储迁移到OSS解决磁盘扩容问题三是引入消息队列做账单生成的异步通知让租客能实时收到缴费提醒。但在扩展之前先把这套SSM版本的业务逻辑吃透才是真正的底子。
