SpringBoot+Vue+MySQL+MyBatis房屋租赁管理系统设计与实现全解析

最近有不少准备做毕业设计或课程项目的朋友跑来问我类似的问题：想做一套带前后端的房屋租赁管理系统，但担心做出来只是一个平铺直叙的增删改查Demo，答辩时老师问两句就露馅。也有一些人是从各种渠道找到了SpringBoot+Vue的房屋租赁管理系统源码，导入跑起来就会遭遇一堆连环境都过不去的麻烦。这篇文章就以这套SpringBoot+Vue+MySQL+MyBatis的完整项目为蓝本，详细拆解从业务理解、表结构设计、后端实现到前端联调的完整链路。

与其说这是一篇代码讲解，不如说这是一份“如果你明天就要动手开发或改造房屋租赁系统，可以照着走一遍”的路线图。比如为什么房屋表要跟楼栋/房间绑定，租约表和账单表为什么不能共用一张表，Vue的登录守卫要拦在哪一层——这些我在文中都会逐个说明，并且把实际踩过的坑一并写出来。

1. 先想清楚：房屋租赁系统到底在管什么业务

很多问题都能在前期需求不清晰的时候埋下来。不夸张地说，这个系统的绝大多数技术难点都来源于“租赁业务的时间、状态和账目关系”。在动手设计表之前，先理解它管理的核心对象。

1.1 先看房屋租赁业务的完整流转链路

一套房子被录入系统，到最终退房清算，通常走这样的链路：

• 房源录入：管理员登记楼栋、房间号、户型、面积、朝向、租金单价、押金规则；
• 房源发布：可选是否同时生成对外展示的信息，供用户端浏览；
• 租客咨询/看房：意向用户在系统上留言或联系房东，产生“看房记录”；
• 签约：租客与房东签署租赁合同，房态从“已出租/未出租”变为“已预定”再变为“已出租”；
• 账单周期：每月/每季度生成租金账单，记录交租、逾期状态；
• 日常管理：水电表录入、报修工单、退租申请等；
• 退租清算：办理退房、结算押金、确认家具家电情况，同时释放房源房态；
• 数据汇总：楼层出租率、租金收入月度统计等。

这个流程如果梳理不清，最容易出现的设计错误就是把“租约表”和“房屋表”耦合成一张表，比如直接在房屋表上加“租客ID”。一旦租客多次续租、历史租客要查询，系统就会极其别扭。

1.2 角色划分决定了功能权限边界

房屋租赁管理系统里的角色可以粗略分成两类：

• 管理员/房东端：维护房源基础数据、审核租客信息、创建/终止租约、处理账单、查看收入统计。
• 租客/用户端：查看可租房源、预约看房、提交租约申请、查看自己的账单、发起报修或退租。

如果带小程序或H5需求，可能还会有一个“访客”角色。做权限控制时，SpringBoot后端用拦截器校验接口权限，Vue前端用路由守卫控制页面可见性。也就是说，前后端都需要校验，不能只防前端按钮隐藏。

1.3 一个可以直接落地的功能清单

我在实际项目里通常建议按下面这个范围去拆，足够应付大多数毕设答辩和基础商用需求：

功能不要盲目贪多。做毕业设计时，八到十个完整闭环的功能比堆二十个零散菜单有说服力得多。

2. 技术选型为什么是SpringBoot+Vue+MySQL+MyBatis

这套组合在课程设计和业内部署中都太常见了，正因为是“经典组合”，踩坑的解决方案往往最容易找到。

2.1 前后端分离的分工逻辑

后端SpringBoot负责提供纯粹的JSON数据接口，前端Vue负责页面渲染和交互。既然是前后端分离，就要注意：

• 后端不要通过模板引擎直接返回HTML页面，接口只返回JSON；
• 前端不能指望后端session保存用户状态，登录成功后后端会签发token，前端每次请求带上token；
• 跨域问题要在后端统一配置拦截器。

这套组合的另一个隐藏优势是，前端工程可以单独部署在Nginx，后端工程是一个标准的Java进程，项目结构和团队协同方式都更接近真实岗位环境。

2.2 MyBatis与MySQL的组合优势在哪里

MyBatis在中小型管理系统里有相当强的存在感，它让开发者对SQL保持完全控制，尤其适合房屋租赁这种带有复杂关联查询和处理业务SQL的场景。比如统计某套房子的历史租约、查询合同快照信息、按月统计租金流水，写SQL比全自动ORM拼JPQL要直观得多。

MySQL则负责数据持久化。在租赁系统里，比较关键的是InnoDB引擎、utf8mb4字符集以及外键逻辑。MySQL不强制你使用物理外键，但在业务代码里必须负责保证引用完整性。

2.3 这套技术栈的边界感

不要指望SpringBoot+Vue这一套能解决高并发、多租户复杂权限、自动化运维等场景。它的价值在于：中小规模业务场景下开发效率高、生态成熟、岗位需求量大。房屋租赁系统并发量并不高——中小公寓可能每天只有几十个租客操作，后端考虑的核心问题不是并发性能，而是业务闭环和代码清晰度。

3. 数据库设计：一张合理的表结构胜过十层代码优化

能支撑“一套房子对应多份历史租约”这种业务关系，是这套系统设计成败的关键。我建议的表结构思路如下。

3.1 核心表结构与关系总览

• 用户表：用户ID、用户名、密码（加密）、角色、手机号、创建时间；
• 楼栋/房源表：楼栋ID与房屋ID是要分开的。如果管理的是小区，还需要楼栋表，房屋属于某个楼栋；
• 租客/联系人表：姓名、电话、身份证、紧急联系方式；
• 租约合同表：租约编号、房屋ID、租客ID、起租日期、结束日期、月租金、押金、状态；
• 账单表：账单编号、租约ID、费用类型、费用金额、出账日期、缴费截止日期、实缴日期、状态；
• 看房/报修/操作日志等辅助功能表。

以一个标准的房源信息模型为例：

3.2 房源状态和租约状态为什么不能混淆

我见过不少新手会把“已出租”当成房屋表上的一个字段，使用状态没考虑时序冲突。举个例子：

• 租客A在3月1号到期，租客B计划3月5号入住。
• 房屋当前状态可以被标记为“即将到期”，也可以提前把B的租约建好。
• 为了避免A、B的数据冲突，需要的是租约的日期区间与房屋状态的联动，而不是一个布尔字段。

这里有一种实用方案：房屋表里维护当前状态，但状态由后台定时任务或业务动作触发更新；租约表负责记录时间有效区间；当创建新租约时，校验起始日期和原租约结束日期不能交叉。

3.3 账单与租约的关系设计要留出扩展空间

房屋租赁中，除了固定月租，还经常出现水电费、维修费、违约金、暖气费等额外费用。为了不让账单表塞进各种特殊字段，建议在账单表中使用费用类型字段：

• account_id：账单ID；
• lease_id：关联租约；
• fee_type：租金/押金/水费/电费/违约金/其他；
• fee_amount：费用金额；
• due_date：应缴截止日；
• pay_date：实际缴费时间；
• pay_status：待支付/已支付/逾期/已结算。

这样设计的好处是，统计月收入时聚合费用类型，或者退租时一次性结算相关费用，都有清晰的数据支撑。后端导出的Excel也能直接按费用类型分类。

4. 后端核心实现：SpringBoot+MyBatis从登录到租约闭环

后端代码的结构，不只影响自己写代码是否爽，还影响后续扩展和答辩讲解。一个清晰的工程结构，本身就说明你“懂分层”。

4.1 后端工程分层约定

通常按这种包来组织：

• controller：接收HTTP参数，调用service层；
• service：业务逻辑处理，事务边界在这一层；
• mapper：MyBatis数据访问接口；
• entity/model：与表结构对应的实体；
• dto/vo：接口入参、出参对象；
• config：跨域配置、拦截器配置；
• common：统一返回结果、异常处理、常量等。

4.2 登录认证逻辑：避免裸奔的Session与Token选择

小型系统也可以用Session，但前后端分离项目里用Token更自然。我本人在这个项目里常用JWT方式实现登录态：

• 用户提交账号密码；
• 后端验证密码后签发JWT，返回给前端；
• 前端将Token存储在localStorage或内存中；
• 每次请求在请求头中添加Authorization；
• 后端拦截器统一校验Token。

为了答辨可解释，你应该把Token设计成短时效（比如2小时），甚至可以加入一个简单的“刷新令牌”逻辑。后端拦截器上放行登录接口，其余接口一律校验。

如果使用Spring Boot框架自带的拦截器实现，可以参考这样一套配置：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(authInterceptor())
                .addPathPatterns("/**")
                .excludePathPatterns("/api/user/login", "/error");
    }

    @Bean
    public AuthInterceptor authInterceptor() {
        return new AuthInterceptor();
    }
}

4.3 房屋出租/续租/退租的状态联动

最核心的业务逻辑是一“租约”动作引发的多表联动。新建一份租约的过程，后端应该做的动作大致包括：

1. 查询房源当前状态；
2. 校验当前租约日期是否冲突；
3. 插入租约合同记录；
4. 更新房源房态为已出租或已预定；
5. 生成首期账单；
6. 记录操作日志。

这些操作必须放在同一个事务里。否则可能出现租约建好了，房源状态没改，后台又把同一套房子挂出去的情况。SpringBoot的@Transactional在service层就能搞定。

我记得第一次做这个模块时，只做了“插入租约”和“更新房屋状态”，漏掉了生成账单。结果第一个月过去，所有租客都没有租金记录，后来手动补了一遍账。所以这个事务边界的思路一定要从一开始理顺。

4.4 MyBatis动态SQL是这类系统的实用密码

房屋列表的搜索条件往往不固定：可能按区域筛选，也可能按租金范围筛选，还可能组合状态和面积范围。MyBatis的<where>和<if>标签非常适合动态构造SQL。

一个典型的房源列表SQL示例：

xml复制<select id="selectHousePage" resultType="com.example.entity.House">
    SELECT * FROM t_house
    <where>
        <if test="buildingId != null">
            AND building_id = #{buildingId}
        </if>
        <if test="minPrice != null">
            AND rent_price &gt;= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND rent_price &lt;= #{maxPrice}
        </if>
        <if test="houseStatus != null and houseStatus != ''">
            AND house_status = #{houseStatus}
        </if>
    </where>
    ORDER BY create_time DESC
</select>

需要注意，小于号在XML中不能直接写<，要写<，不然解析XML时要报错。我第一次写的时候用了?预编译传参，结果SQL里直接写小于号导致XML报错，卡了快半小时。

4.5 账单自动生成与到期提醒的落地方案

如果不想完全依赖定时任务，有一个比较“精妙”的实现是：租约状态为已出租时，每天定时任务扫描次日需要出账的租约，检查当月账单是否已经生成。如果没有就补生成，避免出现断账。

实现上可以引入SpringBoot的@Scheduled注解，在service层扫描：

java复制@Component
public class RentBillTask {

    @Scheduled(cron = "0 0 1 * * ?")
    public void generateMonthlyBills() {
        // 查询所有状态为已出租且满足生成条件的租约
        // 查询是否已生成账单
        // 没有则生成账单
    }
}

当然如果你不想给项目增加“中间件”负担，也可以在管理后台设置一个“手动生成账单”的按钮。做成一个按钮对答辩来说更直观，演示起来不容易被环境问题卡住。

5. Vue前端：页面怎么搭才像个能用的系统

很多朋友对Vue的学习停留在“会写组件、能跑起来”的程度，一旦要把前后端连起来就抓瞎。从这套租房管理系统源码来看，前端设计的核心点有四个。

5.1 Vue项目目录结构建议

• views：按业务模块划分页面，比如house、lease、bill、user；
• router：路由表文件；
• store（或pinia）：用户状态管理；
• api：统一存放请求接口；
• utils：request封装、时间格式化工具；
• components：公共组件，比如房屋状态标签、图片上传组件。

目录清晰到这一步，后续加页面就只需要在views下新建一个目录，并在router和api中补充对应配置，就能平稳扩展。

5.2 登录态与路由守卫：从源头拦住未登录用户

Vue前端路由守卫里，我会判断用户是否存在Token。如果没有请求到登录页，如果有则放行。同时在用户刷新页面时，尝试调用户信息接口恢复登录状态。

核心逻辑片段：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path !== '/login' && !token) {
    next('/login')
    return
  }
  next()
})

上面只是最基础的一层。如果做管理员/租客两种角色，还需要在meta中声明路由需要的角色，并在守卫里二次判断。比如：

javascript复制const role = store.state.user.role
if (to.meta.roles && !to.meta.roles.includes(role)) {
  next('/403')
  return
}

5.3 Axios请求封装：统一错误处理

写一段时期最容易出现的问题是每个页面都在重复this.$axios.get(...)，后端返回401时要改一堆地方。我的建议是把axios这层封装成公共Request工具，统一处理三件事：

1. Token从localStorage取；
2. 响应状态码非200或业务code非成功时统一提示或跳转；
3. HTTP 401时清除登录态并跳回登录页。

javascript复制service.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers['Authorization'] = token
  }
  return config
})

service.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      Message.error(res.message)
      if (res.code === 401) {
        router.push('/login')
      }
      return Promise.reject(new Error(res.message))
    }
    return res
  },
  error => {
    Message.error('网络异常，请稍后重试')
    return Promise.reject(error)
  }
)

5.4 核心页面设计参考

以下是这套系统最值得打磨的几个页面：

• 房源管理页：用表格展示房屋信息，状态用Tag标签高亮；筛选区域放在表格上方；支持查看房屋当前租约状态；
• 租房详情页：可视化展示房源描述、照片、租金；
• 签约弹窗：选择租客、填入租期自动计算总金额，前端预览；
• 账单管理页：账单列表、缴费状态、按账单编号搜索、一键导出；
• 数据统计页：可以使用Ant Design Vue的图表组件展示月度收入折线图和楼栋出租率柱状图。

如果项目是基于Vue3开发的源码，组件库通常首选Element Plus或Ant Design Vue；Vue2老源码则通常配Element UI。改造成本并不高，核心业务结构不变，换组件库时只要注意表单布局和API的差异即可。

6. 拿到源码后从跑通到二次开发的实操顺序

现在市面看到的房屋租赁管理系统源码版本五花八门，有SpringBoot+Vue2的，也有SpringBoot+Vue3+Vite的。不管你手上拿到的是哪一套，运行顺序都是差不多的。

6.1 环境准备的具体版本建议

mysql-connector-java（MySQL 8.x）在SpringBoot 2.7.x版本之后写法有差异，5.x驱动用com.mysql.jdbc.Driver，8.0以后建议用com.mysql.cj.jdbc.Driver。

6.2 启动前最容易出错的顺序问题

正确的顺序是：

1. 创建数据库，导入sql文件；
2. 修改后端application.yml里的数据库账号密码；
3. 启动后端，观察8080端口是否正常；
4. 启动前端，注意Vite/Webpack启动端口；
5. 后端接口报跨域时，优先确认后端Cors配置；
6. 登录时如果报密码校验错误，去数据库手动初始化一条密码为MD5加密后的管理账号。

如果后端连数据库时报警告SSL connection，可以在数据库连接URL加useSSL=false&serverTimezone=Asia/Shanghai。这是MySQL 8一个尤其常见的坑，不加确实也能连，但控制台红字特别多，显得很慌。

6.3 二次开发中容易改崩的几个地方

一旦跑通源码，很多人第一件事就是改菜单名、加字段。这时如果思路没理清，会出现一连串连锁反应。

最典型的是给房屋表加字段。如果你想加“所在楼层”，需要改的地方包括：

• MySQL表增加字段；
• 后端entity类增加属性；
• mapper里的SQL、XML映射要能返回新字段；
• controller涉及的DTO和VO可能也要同步更新；
• 前端列表页和数据表单要新增列；
• 新增的API在axios封装中同步。

所以，任何需要二次开发的字段扩展，都先列清单再动手。前期省时间的快速修改，通常都会在后面某个版本或答辩演示时成为负担。

6.4 答辩演示准备的三个备份计划

这套系统做完后，要提交的既有源码又要有演示数据。这里有几个实际教训值得分享：

• 一定要在一台干净电脑上从零演示一次安装流程，很多同学在教室演示时才发现下载依赖需要外网或代理，卡在Maven下载环节；
• 演示前把MySQL服务设置成开机自启，把后端启动脚本提前配好；
• 准备一份“演示数据剧本”，比如一进去就搜索当前出租房源，点入一套“已租状态”的房子查看租客和账单，比在界面上漫无目的地点来点去更有说服力。

7. 出租率统计与收入报表该怎么设计

报表页是整个系统最容易被忽略、又最容易在答辩中出彩的地方。很多房屋租赁系统源码只实现了CRUD，没有统计，导致演示起来没有“系统感”。

7.1 常见的统计指标

• 出租率：已出租房屋数 / 可出租房屋总数；
• 月收入：当月账单实缴总金额；
• 逾期率：待支付账单数量与账单总数的比值；
• 各楼栋房源数及出租情况。

7.2 后端SQL怎么写示例

统计出租率时，用聚合函数GROUP BY结合条件计数即可：

sql复制SELECT
    b.building_name,
    COUNT(h.house_id) AS total_house,
    SUM(CASE WHEN h.house_status = '已出租' THEN 1 ELSE 0 END) AS rented_house
FROM t_building b
LEFT JOIN t_house h ON b.building_id = h.building_id
GROUP BY b.building_name

统计月收入时，账单表结构会给查询带来很大便利：

sql复制SELECT DATE_FORMAT(pay_date, '%Y-%m') AS month,
       SUM(pay_amount) AS total_income
FROM t_bill
WHERE pay_status = '已支付'
  AND pay_date BETWEEN #{startDate} AND #{endDate}
GROUP BY DATE_FORMAT(pay_date, '%Y-%m')

7.3 前端报表展示选择

前端可以用ECharts来实现柱状图和折线图。因为房屋租赁关键指标通常不超过十个柱子，图表配置并不复杂。只要在Vue组件引入ECharts相关模块，用接口拉到的数据渲染即可，内容不多时不必上重型BI组件。

我遇到的比较棘手的场景是“饼状图需要按楼栋出租比例统计”，这类统计SQL需要在后端拼接好地名字段和value，前端直接接收后填充饼图。当时图省事想在前端拆分处理，结果报表数据变得很难维护。现在我的习惯是：前端只做展示需要的形状转换，数据聚合必须在后端大包大揽。

8. 从这套源码里能提炼出的通用经验

最后再说一些不局限于本项目的通用经验，也是这类管理系统源码真正值钱的地方。

好的管理系统源码不是看它有没有炫酷的组件，而是看它业务逻辑是否闭环。如果核心业务链路能形成“房源录入→签约→账单生成→缴费→退房→数据统计”的闭环，那么这套代码无论怎么包装，都有真正的工程价值。

如果这篇文章是给正在做毕业设计的朋友看的，我建议你把项目按时段拆成三个里程碑：

• 第一周：梳理业务数据表结构，把菜单和数据库建好；
• 第二三周：后端接口全部调通（用自己的方式验证接口）；
• 第四五周：前端联调，并集中精力打磨房源状态和账单逻辑；
• 剩余时间：准备演示视频、撰写论文/报告、整理答辩QA问题。

个人在实际项目中最想强调的一点是：不要只看源码本身，要拿着源码用至少两套业务数据把流程重新走一遍。比如第一套数据：一套电梯公寓的房源，第二套数据：一整栋写字楼的办公间出租。你会更深刻地理解为什么状态设计是独立的、为什么账单需要费用类型字段。这种“用真实场景去检验系统设计”的思路，是源码之外最有成长空间的部分。