做企业级房屋租赁管理系统这套源码之前我先被身边几个做租赁生意的朋友轮番教育过房源几百套租客合同散在文件夹里收租全靠日历提醒月底对账得拿Excel一个个拼。他们需要的不是那种绑定智能门锁的SaaS平台而是能部署在自己服务器上、数据完全可控的管理系统。所以这套项目从立项起的目标就很明确——用SpringBootVueMyBatisMySQL四件套做一套能直接上生产环境的完整源码开发人员拿到手能跑通、能改、能交付。这套系统覆盖了租赁业务里最核心的房、客、合同、钱四条线房东或运营公司可以用它管理房源信息、录入租客资料、生成租赁合同、登记收款退款、处理报修工单管理层还能看到实时数据看板。技术架构是典型的前后端分离单体应用不是微服务但应付几百间房的租务管理绰绰有余。对刚学完Java后端和前端基础、想看完整企业级项目长什么样的开发者来说这份源码最大的价值就是能跑起来的完整项目而不是教程里的零碎Demo。下面我按自己当初从零搭建、踩坑、部署上线的过程来拆解这套系统讲业务也讲实现重点讲哪些地方容易出问题。1. 这套租赁系统到底想解决什么问题1.1 从租务管理的真实痛点说起做租赁管理系统最忌讳上来就画功能大饼。要先把业务痛点理清楚系统才有存在的意义。我在做需求调研时整理了三大高频痛点系统所有模块都是围着它们转的。第一是房源账实不符。运营方手里的房源分布在好几个小区每套房下面又有不同的房间房间到底是空置、在租、还是维修中靠表格登记很难实时更新。第二是合同管理混乱。纸质合同到期没人提醒续签、退租全靠运气押金退还扯皮多。第三是对账效率低。租金收没收、哪套房这个月还没交钱、某租客欠了几个月这些数据散落在聊天记录和本子里月底财务要花两三天才能理清。系统的核心价值就是把这三件事从人肉管理变成系统状态机。房源的每个房间都有状态字段合同的起止日期通过数据库自动计算剩余天数每一笔收款都关联到具体合同和房间这样管理者打开工作台就能看到今日待办、即将到期合同、上月应收实收对比而不是翻聊天记录。1.2 功能模块全景把房-客-合同-钱管起来整个系统的功能模块可以拆成六大块覆盖租赁运营的全流程系统管理用户、角色、菜单权限采用RBAC权限模型管理员给不同员工分配不同操作权限。房源管理按照小区/楼栋-房间两级结构管理房源房间支持新增、编辑、状态变更空置、已租、维护、条件搜索。租客管理登记租客姓名、身份证、手机号、紧急联系人等基础信息并关联其历史租住记录。合同管理创建租赁合同指定租客与房间自动计算起止日期、租期、租金总额支持退租、续租操作。收退款管理租金收款、押金收款、退款登记每笔记录对应合同号可按时间、房间、租客维度筛选。报修与统计租客报修工单的状态流转数据看板展示房间出租率、月度应收实收、合同到期数量。有的读者可能觉得这功能不算多但做企业级系统本来就不是堆功能而是把每个功能做扎实。比如房源管理里房间状态变更和合同生效、退租之间必须有联动逻辑——合同一旦生效对应房间状态必须自动变成已租只有这样才能保证数据一致性。1.3 技术选型为什么是这四件套很多刚开始做项目的朋友总纠结用什么框架我直接说结论这套项目选SpringBootVueMyBatisMySQL不是追求新潮而是为了稳。SpringBoot负责后端接口和业务逻辑自动配置机制极大减少了Spring的XML配置内嵌Tomcat让项目部署变成打一个Jar包这么简单Vue负责前端页面交互配合Element UI组件库开发后台管理界面的效率非常高MyBatis负责数据库访问骨灰级SQL控会更喜欢直接写SQL的感觉MySQL存储业务数据开源、稳定、维护成本低中小型租赁企业的数据量完全够用。我见过不少团队在这种项目上一上来就引入微服务、Redis、MQ结果租务系统本身业务并不复杂分布式架构反而带来部署和运维的复杂度。做企业级项目技术选型的第一原则是够用且可控而不是越高级越好。这套四件套组合任何一个Java开发都能快速接手。2. 环境准备与源码目录先把项目跑起来2.1 版本组合表照着装别用最新版这是我踩过最深的坑所以必须放到最前面说。很多初学者喜欢装最新版环境结果发现SpringBoot版本太高导致各种兼容问题。比如SpringBoot 3.x要求JDK 17及以上把javax.servlet包改名成jakarta.servlet老项目里的拦截器、过滤器代码直接迁移不过去。所以这套源码我推荐使用下面这套保守但经过验证的版本组合组件推荐版本说明JDK1.8企业生产环境主力版本兼容性最好Maven3.6.3与JDK 1.8搭配稳定SpringBoot2.7.x基于JDK 1.8的最后几个大版本之一MyBatis Starter2.2.x配合SpringBoot 2.7使用自动配置正常Node.js14.x或16.x适配Vue 2和旧版构建工具Vue2.6.x Element UI 2.15后台管理系统经典组合MySQL5.7.x稳定性好生产案例多注意如果你执意用SpringBoot 3.x需要同步升级到JDK 17且很多第三方starter可能不支持排查起来非常折腾。我个人建议先按推荐版本来等系统跑通后再考虑升级。2.2 源码目录结构与前后端分离的设计这套源码分为backend后端和frontend前端两个独立工程这是前后端分离的标准姿势。你可以先各自启动通过代理联调最后也可以把前端打包产物放到后端一起启动两种方式我都验证过。后端目录结构大致是这样com.rent.system ├── controller // 接口层接收前端请求 ├── service // 业务逻辑层处理具体规则 ├── mapper // MyBatis的Mapper接口 ├── entity // 实体类对应数据库表 ├── config // 配置类如跨域、拦截器、静态资源映射 ├── common // 通用返回结果、异常处理、工具类 └── resources ├── mapper // MyBatis XML映射文件 └── application.yml前端目录是标准Vue CLI工程src ├── api // 封装axios请求按模块分文件 ├── router // 路由配置含动态路由逻辑 ├── store // Vuex状态管理存用户信息、权限 ├── views // 页面组件按模块目录组织 ├── components // 公共组件 └── utils // request封装、工具函数这套目录的精华在于按模块分包而不是按技术类型分包。controller/service/mapper各自对应一个业务模块比如合同相关的代码都放在contract包路径下新人接手代码时找起来非常快。这也是企业级项目里比较推荐的做法。2.3 数据库初始化与配置文件改动点数据库脚本放在sql/rent.sql目录下里面包括建库建表语句和初始数据。导入方式我建议用命令行而不是图形化工具命令很简单mysql -uroot -p rent.sql导入完成后里面默认有一个管理员账号admin / admin123密码在数据库里是BCrypt加密存储的你别直接往数据库里改明文要改密码就走系统里的修改密码功能。真正需要你改动的配置不多在后端application.yml里主要改三处server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/rent?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码这里有个热词里很多人问的mysql ssl连接错误就是useSSL参数没设置。MySQL 5.7默认会尝试SSL连接如果不显式设为false本地开发环境经常报SSL connection error或警告信息。另外字符集必须指定utf8否则中文字段乱码会折腾你半天。前端配置在vue.config.js里的devServer代理开发模式下前端跑8081端口通过代理把/api开头的请求转发到后端8080端口这样就不会有跨域问题。默认配置已经写好了你只需要确认后端端口一致即可。3. 核心业务模块是怎么一步步落地的3.1 登录认证与RBAC权限动态路由的实现企业级系统第一个要解决的就是权限问题不然谁都能进后台、谁都能删数据。这套系统的权限模型是经典的RBAC基于角色的访问控制数据库里对应五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。登录流程是这样用户提交用户名密码后端用BCrypt校验密码通过后生成一个JWT令牌返回给前端。前端把JWT存在localStorage里每次请求在axios拦截器里带上Authorization头。后端用一个拦截器统一校验如果令牌过期或非法直接返回401前端跳回登录页。权限的精细化体现在菜单上。用户登录成功后后端会根据用户角色返回对应菜单列表前端拿到菜单后动态添加路由也就是热词里提到的Vue动态路由场景。这样做的好处是普通员工登录后根本看不到用户管理这个菜单就算他在浏览器里手动输入管理页面的URL路由没有被注册也会被拦下来。这种菜单隐藏路由拦截双保险才是企业系统该有的姿态。我之前单独写过一篇动态路由的实现细节这里给个核心思路// router/index.js const fixedRoutes [...]; // 登录页、首页等固定路由 const dynamicRoutes []; // 需要权限才能访问的路由 router.addRoutes(dynamicRoutes); // 登录后根据权限动态添加这里有个小坑如果用户退出登录后没有重置路由下次换个账号登录前一个账号的动态路由还在内存里。别忘了在退出时window.location.reload()刷新页面把路由恢复初始状态。3.2 房源管理多条件分页查询的动态SQL房源管理模块看起来就是一张表的增删改查但企业级系统的增删改查和课程Demo有个明显区别查询条件多且分页。用户可能按小区名查、按房间状态查、按户型查、按租金区间查条件可以任意组合这就要靠MyBatis的动态SQL来解决了。先看页面字段房源列表的搜索栏里有关键词输入匹配房源名称或小区地址、房间状态下拉框空置/在租/维护、租金范围两个输入框。对应的Mapper XML里是这个样子select idpageList resultTypecom.rent.system.entity.Room SELECT r.*, h.house_name AS houseName FROM t_room r LEFT JOIN t_house h ON r.house_id h.id where if testkeyword ! null and keyword ! AND (h.house_name LIKE CONCAT(%, #{keyword}, %) OR r.room_no LIKE CONCAT(%, #{keyword}, %)) /if if teststatus ! null and status ! AND r.status #{status} /if if testminRent ! null AND r.rent #{minRent} /if if testmaxRent ! null AND r.rent lt; #{maxRent} /if /where ORDER BY r.create_time DESC LIMIT #{offset}, #{pageSize} /select你可能注意到我写模糊查询用的是CONCAT(%, #{keyword}, %)而不是%${keyword}%。后者写法更短但${}是字符串拼接存在SQL注入风险而且遇到特殊字符容易出问题。用CONCAT函数配合#{keyword}预编译才是规范做法。我见过不少项目图省事这里必须纠正过来。还有一个细节是lt;。在XML文件里符号会被当成标签开始解析所以小于号必须写成lt;。这个错误很隐蔽写XML时一不留神就会掉坑里报错信息往往是元素内容必须由格式正确的字符数据或标记组成。记住在MyBatis XML中可以正常写必须转义或者用![CDATA[ ]]包起来。3.3 租赁合同时间计算与到期提醒合同模块是整个系统的业务核心。一张合同要关联三个对象租客、房间、收款记录。创建合同的页面里运营人员选择租客从已登记的租客里选、选择房间只看状态为空置的房间、填写起租日期和结束日期系统自动计算出总租金。有几个关键的业务逻辑我得展开说。合同编号的生成规则我是这样设计的HT 年月日 序号比如HT20250112001。这个编号在数据库里建立唯一索引后续所有收款记录、退款记录都拿合同编号做关联方便追溯。租金计算不能简单写成月租金乘以月数因为合同可能不是整月比如1月15日入住、租到3月10日。这套系统里我封装了一个租金计算工具类按实际天数计算月租金并支持押一付一、押一付三、半年付、年付四种付款方式。具体实现上是先把起止日期拆分为整月部分和零散天数部分整月按约定月租计算零散天数按月租金除以当月天数乘积。到期提醒的做法是定时任务SQL组合。后端用Spring的Scheduled注解每天凌晨跑一次任务扫描所有状态为生效的合同查出结束日期在30天内到期的合同生成提醒记录写入提醒表。前端首页的待办事项就是从提醒表里查出来的select idgetExpiringContracts resultTypeContract SELECT * FROM t_contract WHERE status 1 AND end_date BETWEEN CURDATE() AND DATE_ADD(CURDATE(), INTERVAL 30 DAY) /select合同状态流转也要把好关创建后是待生效收款押金后变为生效中到期自动变为已到期运营人员操作退租变为已退租。每次状态变更都往合同操作日志表写一条记录这样后面万一出现纠纷能查到完整的操作轨迹。3.4 收退款记录账目怎么跟合同联动收退款模块负责处理钱逻辑必须严谨。系统里的每一笔收入都关联到具体合同页面展示的字段包括合同编号、房间号、租客姓名、收费项目房租/押金/其他、金额、收款方式、经办人、收款时间。设计上有个关键点收退款表和合同表是多对一关系而不是简单在合同表里加一个已收金额字段。为什么要这样因为合同可能会多次收款比如半年付的合同分两次收如果只在合同表里存累计金额那收一笔改一次并发操作下很容易数据错误。拆成独立的支付记录表后合同总收金额由SQL聚合查询得出SELECT contract_id, SUM(amount) FROM t_payment WHERE contract_id 1 GROUP BY contract_id;退款逻辑反着来退款金额必须校验不能超过该合同已收金额否则系统直接拒绝。这也是为了数据安全——未收款先退款这种事绝对不能发生。财务人员最头疼的月度对账系统里有一个汇总统计接口查询某段时间内每天的应收、实收、欠费金额。实现上就是按合同关联支付记录再按日期做聚合。这个接口的SQL写得稍复杂但其实就是把业务规则翻译成SQL的过程一旦写好了月底财务报表几分钟就能出来。4. 前后端联调中我实测过的那些坑4.1 跨域问题开发代理与CORS要一起处理前后端分离联调第一个遇到的就是跨域。前端在8081端口后端在8080端口浏览器直接请求肯定报跨域错误。我的处理方式是前端代理为主后端CORS兜底。前端在vue.config.js里配置代理devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端发起的/api/login请求会被代理转发到后端浏览器看起来是同源请求跨域问题就消失了。后端同时配置CORS是为了防止万一前端不走代理直接请求后端IP的情况比如后续有人用Postman测试接口、或者前端独立部署时直连后端。配置CORS不复杂一个配置类搞定但有几个参数要注意允许的域名别用*改成前端实际部署地址allowedHeaders要包含Authorization否则前端带JWT请求会被拒绝。经验之谈生产环境如果前后端分开部署Nginx反向代理是最干净的方案后端的CORS配置可以保持宽松Nginx层面去控制跨域如果前后端打包在一起CORS配置基本都用不上因为同源了。4.2 MyBatis XML里的三个隐蔽错误这段时间我帮不少人看过这套系统的报错发现问题几乎都出在MyBatis的XML映射文件里。这里把最常见的三个坑集中说一下。第一个是#{}和${}混用。分页查询里LIMIT后面的offset和pageSize我见过有人写成#{offset}大部分时候没问题但如果数据库驱动不支持预编译设置参数就会报错。更隐蔽的是ORDER BY排序字段如果把列名写成#{sortField}生成的SQL会是ORDER BY create_time字符串当列名用查询结果完全不对。所以记住排序字段、表名这类不能参数化的地方用${}但必须自己做好白名单校验值类型条件一律用#{}。第二个是XML转义问题我前面提到过lt;。还有动态SQL里如果if判断的字符串比较写着写着就漏掉转义编译不报错运行到那一段才报XML解析异常排查起来很折磨。第三个是主键回填。插入合同记录后后面的退款记录要引用合同ID如果Mapper没有配置useGeneratedKeys你拿到的实体对象ID永远是null接着往下做事必报错或者存出脏数据。规范写法是在插入语句上加insert idinsertContract useGeneratedKeystrue keyPropertyid INSERT INTO t_contract ... /insert4.3 Vue路由刷新404与打包部署问题热词里vue打包放进springboot中这个需求我太熟了。Vue默认用history模式路由路径长得像http://localhost:8080/contract/list这种路径在Vue开发服务器里没问题但如果你把前端打包后的dist目录直接丢进SpringBoot的static文件夹刷新/contract/list页面就会404——因为后端Tomcat压根没有这个路径的映射它只会找/index.html。解决办法有两个。一是前端路由改用hash模式URL变成http://localhost:8080/#/contract/list刷新时不会请求真实路径。这个方案简单但URL不好看。二是保持history模式在后端加一个转发规则所有不存在的非静态资源路径都转发到/index.html。推荐第二种方案如下Configuration public class WebConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController(/{spring:[^\\.]*}).setViewName(forward:/index.html); } }这里面[^\\.]*的意思是不含点号的路径才会转发这样图片、JS、CSS等静态资源不会受影响只有类似/contract/list这样的前端路由会被转发到index.html然后由Vue路由接管渲染。4.4 图片上传与文件存储的取舍系统里房源管理支持上传房间照片、户型图片租客管理支持上传身份证照片。图片存储是个容易被低估的问题。我最初的实现是把图片保存到本地磁盘数据库只存相对路径然后通过SpringBoot的静态资源映射暴露出去。配置很简单spring: resources: static-locations: file:D:/upload/但部署到服务器后问题来了如果服务器磁盘满了或者项目重启导致上传目录丢失图片就全挂了。而且如果以后要做多实例部署本地存储的图片在另一台机器上根本访问不到。所以我的建议是小规模部署用本地存储没问题但数据目录一定要和项目目录分开并做定期备份如果客户预算允许直接上对象存储如阿里云OSS、腾讯云COS上传成功后把URL存进数据库永久有效且不占服务器空间。另一个和图片相关的小功能是图片预览。Vue里展示图片URL如果图片路径是后端相对地址必须在前端拼接基础路径。我在axios的request封装里统一处理了响应头里的图片URL自动补全为完整地址这样页面里直接el-image :srcrow.photoUrl就能显示不需要每个页面单独处理。5. 打包部署的两种方式与后续扩展思路5.1 方式一前端打包直接放进SpringBoot这种方式适合部署简单、一台服务器搞定的场景也是热词里vue打包放进springboot中的完整答案。第一步前端构建。在frontend目录下执行npm install npm run build构建完成后dist目录里是静态文件。第二步把dist下的所有文件复制到后端src/main/resources/static目录里。第三步重新打包后端mvn clean package -DskipTests得到的Jar包就自带了前端页面。启动时访问http://服务器IP:8080直接看到登录页面前后端同源没有跨域问题。这种方式最大的优点就是部署简单一个Jar包搞定特别适合客户那边没有运维人员、只能用java -jar命令启动的场景。缺点是前端每次更新都要重新打后端包迭代频繁时会麻烦一些。5.2 方式二Nginx反向代理独立部署如果项目后期前端更新频率高或者需要单独给前端配置HTTPS证书那就走前后端独立部署。前端构建产物dist上传到服务器的/usr/share/nginx/rent-web目录后端Jar包正常运行在8080端口。Nginx配置如下server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/rent-web; index index.html; try_files $uri $uri/ /index.html; # 解决history模式刷新404 } # 后端接口 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里面的try_files $uri $uri/ /index.html是Nginx版的路由兜底原理和SpringBoot转发一致找不到真实文件的路径就交给前端路由去处理。这套方案的前端更新只需要替换dist目录文件然后nginx -s reload后端可以完全不动。5.3 这套系统可以往哪个方向继续扩展项目做完交付之后我一直在思考它的边界在哪里。按企业级房屋租赁管理系统的定位目前这套源码算是个扎实的基础版但有几个扩展方向建议有需要的读者根据自己的业务场景去加。第一是消息提醒的多元化。目前到期提醒只在系统内部展示接上短信或微信模板消息后运营人员不用天天登录后台就能收到提醒。实现上可以在定时任务里增加调用短信平台的HTTP接口的代码工作量不大但感知提升明显。第二是电子合同。现在的系统还停留在管理合同信息的层面如果业务正规化需要接入电子签章服务把合同生成PDF、在线签署、自动归档。前端展示PDF这块已经有很多现成方案前端预览合同打印件是很自然的延伸。第三是数据报表更精细化。目前的数据看板展示基础指标后续可以增加租客流失分析、房源空置周期统计、同户型租金趋势分析。这些都是基于现有表数据就能实现的统计需求SQL写好后前端用折线图、柱状图展示即可。从我个人的实操体会来说做完一套完整的企业级项目收获最大的不是某个框架的API怎么调而是建立了一种从业务需求倒推技术实现的思维方式。比如合同到期提醒先想清楚谁能受益、什么时候触发、提醒内容是什么再考虑定时任务怎么写、SQL怎么查比如权限控制先分析角色有哪些、菜单怎么分再去实现动态路由。这套源码的每一行代码背后都有对应的业务决策你把业务逻辑理顺了技术实现自然水到渠成。最后再分享一个建议拿到源码之后别急着满项目找彩蛋建议从启动日志开始看沿着一个创建合同-关联房间-收款-看统计的完整流程走一遍比只看单个模块的理解效果好得多。