SpringBoot+Vue+MySQL打造房屋租赁管理系统：从设计到部署

做一套房屋租赁管理系统其实没有想象中那么复杂，但也没想象中那么简单。老实说，这套系统最吸引我的点是"Info【可直接运行】"这几个字，全栈项目最怕的就是拿到源码跑不起来，环境问题、依赖冲突、数据库版本不一致，随便一个就能卡一整天。而SpringBoot后端加Vue前端加MySQL这套组合，是目前国内中小型管理系统开发中最常见也最稳妥的技术栈,不管是拿来学习、二次开发，还是直接在真实业务中部署使用，都有很强的参考价值。这篇博文我会从需求拆解、前后端架构、数据库设计、启动部署到踩坑经验，完整讲清楚这套系统是怎么运作的，希望给正在做同类项目或者准备学习全栈开发的朋友一份能"直接抄作业"的参考资料。

很多人一听到"管理系统"就觉得是CRUD堆功能，但其实租赁管理这个场景有它非常独特的业务逻辑。房屋的状态流转、租客和合同的时间关联、租金账单的计算和逾期处理，这些都不只是一个简单的增删改查。网上能找到的很多源码，要么只做了个壳子，要么业务逻辑和实际使用脱节，真正能落到日常管理里的其实不多。

1. 先拆解需求：一套租赁管理系统到底要解决什么问题

1.1 租赁业务的核心角色与流程

做系统之前要先搞清楚谁在用。这套系统面向的角色其实很清晰，主要就是管理员（通常是小规模房产的运营方或二房东）和租客。

从管理员的视角看，日常工作量集中在这么几块：录入房源信息、处理租客入住和退租、跟进合同到期时间、按时收租金、记录报修和投诉。很多小规模管理者还在用Excel甚至纸质本子管理，查一处信息要翻半天，遇到合同到期忘记提醒，租金漏收也是常有的事。

从租客的视角看，他们想知道的是：我租的房什么情况、什么时候交租金、物业费怎么交、有问题怎么报修。如果能有一个界面让租客自己查看这些信息，管理员的沟通成本会大幅下降。

所以核心业务流程是这样闭合的：房源登记入住签约抄表收租报修处理退租结算。每一步都依赖前一步产生的数据，比如退租结算需要调取入住时的押金记录、历史账单明细、水电表读数，如果这些数据散落在不同表格里，对账就是一场灾难。这套系统的价值就是把整条链路的数字记录串起来。

1.2 六大核心功能模块

拆开来看，这个系统主要包含六大模块，每个模块解决一类明确的业务问题：

房源管理模块：维护所有房屋的楼栋、门牌号、户型、面积、朝向、租金单价、当前状态。状态至少要区分"已出租"和"待出租"，这样管理员能快速知道哪些房子还能租出去。有些项目还会加装修情况、家具配套等字段，看具体场景需求。

租客管理模块：登记租客的基础信息（姓名、联系方式、证件号、紧急联系人等），并且要和合同、房源关联起来。一个租客可以租多套房，一套房在不同时段也会有不同租客，这里的历史记录一定要保留，不能租客退租后把信息直接删掉。

合同管理模块：这是整条业务链的核心。租赁起止时间、租金金额、押金规则、缴费周期（月付、季付）、物业费承担方式、违约条款等。合同状态也要管理好：生效中、即将到期、已到期、已终止。系统要能根据合同到期日自动生成提醒。

收租与账单模块：根据合同自动生成每期租金账单，记录实收金额和收款时间，支持部分缴费和逾期标记。每个房源一个账单列表，每笔钱都能对上号，年底做统计时不用再从微信聊天记录里翻转账凭证。

报修与投诉模块：租客提交报修单，管理员接单处理，完成后反馈结果。这个模块看似不起眼，却是租客体验中感知最强的部分，处理不及时很容易积累矛盾。

统计与提醒模块：营收总览、在租房源数、即将到期合同列表、逾期账单列表。管理系统的价值不只在于记录，更在于通过提醒机制减少人工漏项。

1.3 为什么技术栈选SpringBoot、Vue和MySQL

先说后端。SpringBoot是目前Java后端开发事实上的主流框架，用它做管理系统非常顺手。自动配置机制把大量基础工作做好了，团队开发时接口层的开发效率很高，加上Spring Security或者JWT做登录鉴权很成熟，做一套带角色权限的管理后台选它没有毛病。

前端用Vue则是看中它的组件化开发思路和相对平缓的学习曲线。Element UI或者Element Plus组件库提供了现成的表格、表单、弹窗、日期选择器，管理系统的页面形态又高度统一，无非是"表单收集数据、表格展示数据、弹窗确认操作"，组件库能省下大量重写样式的时间。

数据库用MySQL的理由更简单，它足够稳定、生态成熟、部署方便，绝大多数开发者本地都装了。从数据量来说，一套租赁管理系统的数据规模连MySQL性能的皮毛都用不到，选它是最稳妥的做法。也正因如此，这套源码对运行环境的要求并不苛刻，普通笔记本完全带得动。

2. 系统架构与数据库设计：顺便讲清楚表与表之间的关系

2.1 整体分层架构

整套系统按标准的前后端分离结构组织。后端起在8080端口，前端通过代理转发请求，避免开发环境下的跨域问题。后端内部采用经典三层架构：

控制层负责接收前端请求和参数校验，不写业务逻辑；服务层处理具体业务规则，比如生成账单、校验合同重叠日期；数据访问层用MyBatis Plus操作数据库，简化单表CRUD的工作量。三层分开的好处是后期加功能时修改范围可控，不会动一处牵全身。

认证方面，系统采用基于Token的登录机制。用户登录成功后后端返回Token，前端拿到后存在本地，之后每次请求在请求头里带上。拦截器会校验Token的合法性和有效期，同时根据用户角色控制接口访问权限。管理端和租客端看到的菜单和操作按钮完全不一样，这个逻辑在路由和按钮级权限两个层面处理。

2.2 核心表结构设计逻辑

数据库表不多，核心的几张我大致说一下。

用户表：存管理员和租客账号，字段包含用户名、加密后的密码、角色类型、昵称、手机号。这里的角色类型区分了管理端和租客端，租客登录后会自动关联自己的租赁信息。

房源表：房屋编号、所在楼栋、户型、面积、朝向、租金单价、押金金额、当前状态（0待租1在租2维修中）、备注。其中"当前状态"字段看似简单，但实际影响很多业务逻辑，下架、新建合同时都要先检查房源状态。

租客表：姓名、性别、手机号、证件类型及号码、紧急联系人、备注。注意租客表和用户表是分开的，用户表管登录，租客表管信息，两者通过外键关联，好处是即使同一租客换了手机号注册新账号，历史租赁记录依然能关联上。

合同表：合同编号、房源ID、租客ID、起租日期、结束日期、租金单价、计费周期、押金金额、合同状态、创建时间。合同表同时关联房源和租客，是整套系统业务关系的枢纽。

账单表：账单编号、合同ID、费用类型（租金/押金/水电）、应收金额、实收金额、账单周期、缴费状态（未缴/部分缴纳/已缴纳）、缴费时间。生成账单的动作一般放在服务层，创建一个新合同时按计费周期自动生成未来若干期的账单记录。

抄表表：房源ID、上次读数、本次读数、抄表日期、费用。抄表数据分析出用电量后带入租金系统计算费用，这块做得精细一点能避免很多纠纷。

维修记录表：报修单号、房源ID、报修人、问题描述、处理状态、处理结果、创建时间、完成时间。

整个库的设计核心是合同表这张关系枢纽，房源和租客是多对多关系，但通过合同表可以查清某个房源的历史租客，也可以查清某位租客租过哪些房源，对账和复盘都非常便利。

2.3 几张关键表的关联关系速查

3. 前端页面的设计思路：管理后台与租客端分开做的原因

3.1 页面整体结构与路由组织

前端采用Vue + Element UI构建，按照角色维度拆成两套界面。

管理后台的首页是数据概览，用卡片展示在租房源数、待收租金、待处理报修、即将到期合同，下面再放最近半年的营收趋势图。这些数据都有后端统计接口支撑，查询时按月份聚合，SQL写个GROUP BY就够。

侧边栏菜单则按业务模块组织：房源管理、租客管理、合同管理、账单管理、报修管理、数据统计。每一块进去都是标准的"顶部操作区 + 中间表格区 + 右侧弹窗编辑"布局。表格区支持分页和条件筛选，方便管理员在海量数据中快速定位目标记录。

租客端的页面则精简很多。登录后首页展示自己当前合同的基本信息，包括房源位置、租金标准、租期起止；我的账单列表里能看到每期应收应付；报修页面提交一个表单，填描述和上传图片即可。租客端做轻量，目的就是让非技术人员也能零学习成本地上手。

3.2 几个核心页面的交互细节

房源管理页的表格列设计很讲究。除了基本的楼栋门牌、户型面积、租金单价外，状态列一定要用Tag标签展示，待租绿色、在租蓝色、维修中橙色，扫一眼就能掌握全局。操作区的"新建房源"按钮和表格行的"编辑/下架"按钮要分开，行内按钮强调易用性，页面顶部按钮负责新增场景。

合同管理页是我认为交互上最需要下功夫的一页。新建合同时，房源下拉选择器要联动显示当前房屋的租金和状态，选完房源后自动带出，减少手工输入。日期范围选择器选择租期，系统会在提交时校验和现有合同是否有时间重叠。合同列表里的状态列同样用彩色Tag提醒，即将到期的合同额外用黄色高亮。

账单管理页的核心是"一键生成账单"功能。管理员选择合同后，系统自动计算当前周期应缴金额，生成待缴账单。账单列表的筛选维度要足够丰富：按房源、按租客、按状态、按周期。实收操作弹窗里可以修改实收金额、填写收款方式和收款时间，做部分缴费时自动更新账单状态为"部分缴纳"。

登录页的设计也要提一句，页面同时支持管理员和租客两种角色入口，登录后根据角色跳转到不同路由。这里有个容易踩的坑，前端路由守卫要同时处理"未登录"和"角色不匹配"两种情况，否则会出现已登录用户手动改URL访问对方页面却毫无拦截的问题。

3.3 前后端联调的关键点

联调阶段最常用到的是代理转发。Vue项目的开发服务器配置里加一个代理，把前端的8080请求转发到后端的8080接口，前端代码里统一封装axios实例，baseURL指到/api即可，这样上线后只需简单调整Nginx的反向代理配置就能无缝切换。

接口响应格式建议全项目统一：

{ "code": 200, "message": "操作成功", "data": {} }

前端在axios响应拦截器里统一判断code值，非200的情况弹错误提示。这样后端不管哪个接口出错，前端处理逻辑都是同一套，不用每个页面单独写错误处理。

4. 从零启动：完整的环境准备与运行步骤

4.1 环境要求与版本选型

我自己实际跑通这套源码用的环境大概是这样的：

这套组合几乎没有任何特殊环境要求，全部是主流版本。唯一要注意的坑是Node版本过高时，某些低版本的依赖包可能安装失败，此时建议把Node降级到16版本再用。

4.2 数据库初始化步骤

拿到源码后，先打开数据库文件夹，找到SQL初始化脚本。使用命令行或者数据库可视化工具执行，顺序不能乱，先创建数据库，再执行脚本。

CREATE DATABASE IF NOT EXISTS house_rental DEFAULT CHARACTER SET utf8mb4;

执行完脚本之后确认一下表是否全部生成，正常会看到用户表、房源表、租客表、合同表、账单表这样一套核心表。然后检查数据是否写入成功，特别是用户表里通常应该预置了一条管理员账号记录，登录时要用。

4.3 后端启动配置

用IDEA打开后端项目后，先等Maven把依赖拉完。这个阶段最容易出问题的是网络原因导致依赖下载失败，解决方案就是配置国内镜像源。在Developer工具里设置阿里云镜像仓库，重新刷新就能解决。

接下来修改数据库连接配置：

spring: datasource: url: jdbc:mysql://localhost:3306/house_rental?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码

启动后端前，确认三件事：MySQL服务是否开启、数据库账号密码是否和配置一致、端口8080是否被占用。都没问题的话启动入口类，看到Spring Boot的启动日志中有"Started"字样和Tomcat端口号，后端就起来了。

4.4 前端启动与本地联调

开第二个终端窗口，进入前端项目目录，先装依赖：

npm install

如果安装过程报错或者特别慢，一样先把npm镜像切换成国内源。

npm config set registry https://registry.npmmirror.com

安装完成之后启动开发服务器：

npm run dev

看到Compiled successfully之后，浏览器打开对应端口，通常就是8081这样的端口。这时如果前端能出现登录页面，说明前后端通信链路通畅，用预置管理员账号登录就能进入管理后台。

4.5 一个特殊提醒：登录后页面白屏如何排查

这种情况多半是前端路由没有正确匹配。先看浏览器控制台有没有报错，再确认登录成功后是否存了Token以及跳转的路径是否存在于路由表里。管理后台和租客端的路由是两套，管理员账号如果被前端路由守卫判定为"无权限访问租客端"，就会一直白屏。排查思路是从网络请求开始看，登录接口通不通、用户信息接口通不通、再到路由和权限判断，一层层缩小范围。

5. 源码落地过程中的经验之谈与优化方向

5.1 最容易踩的五个坑

第一，数据库连接失败。这个坑出现频率最高，多半不是SQL脚本的问题，而是密码不一致或者MySQL服务没启动。Windows下记得先确认服务列表里MySQL服务状态为"正在运行"。

第二，后端启动后接口404。原因通常有两个，一是启动类没放在正确包路径下，导致Spring无法扫描到Controller；二是接口地址写错，前端调用的路径和后端声明的路径不一致。

第三，Vue项目npm install卡住不动。解决方法是切换镜像源后删除node_modules和package-lock.json重新安装。

第四，跨域请求被拦截。开发环境下通过Vue的代理转发解决，生产环境需要在Nginx里配置反向代理。

第五，日期格式显示成时间戳。在SpringBoot的配置里统一处理一下，返回给前端时会自动格式化成指定字符串格式。

前端请求本地代理配置示例：

// vite.config.js 或 vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

5.2 系统上线前建议做的改进

这套源码直接运行当然没问题，但真要部署到真实生产环境，有几件事我强烈建议先做。

第一，把默认的管理员密码改掉，密码存储用的加密算法确认一下强度是否够。第二，数据库账号不要用root连应用，建议创建独立的数据库账号，只授予这个库的增删改查权限。第三，给MySQL做定时备份，租赁系统的核心资产就是那些合同和账单数据，丢哪一行都麻烦。

接口层面的改进空间也很大。目前如果并发量不大，单机部署就够。如果未来房源数量上千、租客数量达到几千，建议把统计类接口的SQL加上索引优化，特别是按合同状态、房源ID、账单状态这几个高频查询条件建联合索引。数据量再大的话可以引入Redis做热门数据的缓存，不过以租赁系统的业务规模来说，这一步目前看不必要。

5.3 可以继续扩展的方向

这套系统的架构留了很好的扩展空间。业务层面，可以加看房预约功能、电子合同签署、租金逾期自动计算滞纳金；体验层面，可以接入微信公众号消息提醒，租客绑定账号后实时接收缴费和到期通知；管理层面，可以加操作日志记录，整个系统做了哪些修改一清二楚。

从技术角度，如果想进一步提升，可以把登录对接统一认证服务、引入Redis管理Token会话、前端换TypeScript重写、后端拆分成微服务，但这些都属于超出"可直接运行"范围的需求。就这套系统本身而言，目前的架构已经足够清楚，很适合作为学习SpringBoot和Vue全栈开发的练手项目，也能直接支撑小规模的真实业务。

5.4 个人的实际体会

我把这套源码完整跑通过之后，最大的感受是：管理系统的难点其实不在技术，而在对业务的理解。一个合同状态字段的设计、一个账单生成时机的选择，都会直接影响使用体验。这套项目中合同和账单之间的联动做得比较合理，这恰恰是很多同类源码最薄弱的地方。

如果你打算在此基础上做二次开发，建议先按自己的管理流程把核心字段画一张草图，再对照源码里的表结构做取舍。别人的表设计和你的实际业务有出入是很正常的，改表字段可比改业务逻辑容易得多。跑通只是第一步，跑出自己的业务逻辑才是这套源码真正给你的东西。最后提醒一句，改动前记得先备份原库，我就因为调试时误改了一条账单数据，对账时多花了半小时。