SpringBoot+Vue房屋租赁管理系统全栈实战开发与部署指南

做了大半个月，终于把基于SpringBoot+Vue的房屋租赁管理系统完整跑通了。这几天趁热打铁把整个项目的开发思路、核心模块、关键代码和踩坑记录整理出来，给准备做毕设或者正在学习全栈开发的朋友一个参考。

这个项目我用的技术栈是SpringBoot + MyBatis + MySQL做后端，Vue + Element UI做前端，涵盖了房屋租赁业务中的房源管理、租约合同、账单缴费、报修管理等核心环节。整套系统从前端页面到后端接口，再到数据库设计，都是完整可运行的，不是那种只有几个demo页面的半成品。

1. 项目整体设计与技术选型

先聊聊技术选型的问题。我见过不少同学一上来就纠结用SSM还是SpringBoot，用JSP还是前后端分离，结果纠结了半个月代码还没写一行。其实对于房屋租赁管理系统这种典型的管理信息系统，选型逻辑非常清晰：SpringBoot负责快速搭建后端服务，MyBatis负责数据库操作，MySQL存数据，Vue做前端页面，这套组合是当前JavaWeb领域最成熟、资料最多、遇到问题最容易搜到解决方案的搭配。

1.1 为什么选择SpringBoot而非传统SSM

传统SSM（Spring + SpringMVC + MyBatis）需要大量XML配置，光是spring、springmvc、mybatis三个配置文件就能写上百行，还要处理各种jar包版本冲突。SpringBoot的核心价值就两个字：简化。内嵌Tomcat容器，不需要额外部署war包，通过starter依赖一键引入各类组件，配合application.yml统一管理配置，开发效率提升非常明显。

我用的是SpringBoot 2.7.x版本，之所以不选最新的3.x，是因为3.x基于JDK 17，很多学校的服务器环境还在用JDK 8，而且部分依赖对3.x的兼容性还有坑。这一点在毕设答辩时也可以作为技术选型的理由：选用稳定版本而非最新版本，保证项目可运行性优先。

1.2 前端采用Vue的必要性

房屋租赁管理系统涉及多个角色（管理员、房东、租客），页面多、交互多，如果用传统JSP模板渲染，前后端代码耦合严重，后续维护会非常痛苦。采用Vue + Element UI的方案后，前端通过axios调用后端RESTful接口，职责边界清晰。

Vue的核心优势是组件化和响应式数据绑定。以房源管理为例，房源列表、房源搜索、房源详情三个页面可以拆成三个组件，通过路由切换；列表数据的增删改查只需要操作data对象，页面自动更新，不需要像jQuery那样手动操作DOM。我选择的是Vue 2 + Element UI的组合，稳定性好，Element UI的组件库恰好适配Vue 2，毕设项目完全够用。

1.3 数据库设计的核心思路

房屋租赁业务的核心实体包括用户、房源、租约、账单、报修记录。在数据库设计上，我遵循了几个基本原则：主键统一用自增id，时间字段用datetime类型，金额字段用decimal(10,2)避免浮点误差，逻辑外键建立索引保证查询效率。

从ER关系来看，用户和房源是1对多的关系（一个房东可以发布多套房源），用户和租约是1对多的关系（一个用户可以签多个租约），房源和租约是1对1的关系（一套房源同一时间只能有一个有效租约）。理解清楚这些关系，建表就有了骨架。

2. 核心功能模块拆解与实现

房屋租赁管理系统听起来简单，但真正拆解业务需求时，细节比想象中多很多。我把整个系统拆成六个核心模块，分别说明业务逻辑和实现思路。

2.1 用户认证与角色权限管理

用户模块是系统的入口，涉及注册、登录、角色识别三个环节。系统内置三种角色：管理员、房东（出租方）、租客（承租方），不同角色登录后看到的菜单和操作权限完全不同。

登录逻辑我用的技术方案是JWT（JSON Web Token）做无状态认证。用户登录成功后，后端生成一个包含用户id和角色的token返回给前端，前端存储token并在后续每个请求的请求头中携带。后端通过拦截器统一校验token有效性，并解析出当前用户身份。

// JWT工具类核心方法 public String generateToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

这里要提醒一个细节：JWT的有效期设置很关键。我设置了24小时，对于毕设演示场景够用，但如果做生产环境，建议配合refresh token机制，否则用户每24小时需要重新登录。

2.2 房源管理模块

房源管理是系统的核心业务模块。房东登录后可以发布房源，填写房源标题、小区名称、户型、面积、租金、押金、地址描述、配套设施等字段，并上传图片。租客端通过不同的查询条件（区域、价格区间、户型）筛选房源，查看房源详情并发起签约请求。

发布房源的核心接口关键点在于图片上传。我采用的方式是本地存储：前端通过Element UI的upload组件将图片上传到后端接口，后端将图片文件保存到服务器本地的upload目录，并将访问路径存入数据库的pic字段。

@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { // 生成唯一文件名，防止覆盖 String originalFilename = file.getOriginalFilename(); String fileName = System.currentTimeMillis() + "_" + originalFilename; String filePath = UPLOAD_DIR + fileName; file.transferTo(new File(filePath)); return Result.success("/upload/" + fileName); }

房源状态管理上，我用一个status字段控制，包括：待审核（0）、已上架（1）、已出租（2）、已下架（3）。管理员可以审核房东发布的房源，审核通过后才在前端展示给租客，这个设计保证了对内容质量的管控。

2.3 租约与签约模块

租约模块是最容易出现业务逻辑漏洞的地方。核心难点在于：一套房源不能同时被多个有效租约占用。如果并发场景下处理不当，就可能出现一房多租的问题。

我的解决方案是在数据库层加约束：租约表建立house_id和status的联合唯一索引，但MySQL对包含status字段的唯一索引在多个有效状态时不友好。最终我采用了更简单的方案：创建租约时先查询该房源是否存在状态为有效（status=1）的租约，如果存在则拒绝。

-- 创建租约前检查房源占用情况 SELECT COUNT(*) FROM lease WHERE house_id = #{houseId} AND status IN (1, 2) AND end_date >= NOW()

2.4 账单与租金管理

租金计算这块，我设计了根据租约周期自动生成账单的机制。每份租约签订后，系统根据租约开始时间和结束日期、月租金金额，按月生成应收账单。

账单表的字段包括：账单编号（唯一）、租约id、费用类型（租金/押金/水费/电费）、金额、状态（未缴/已缴/逾期）、生成日期、缴费日期。缴费操作由租客发起，点击缴费按钮后模拟支付流程，更新账单状态为已缴，并记录缴费时间。

实际的业务中还会遇到押金退还、水电费代收等场景，在毕设中可以把逻辑简化，但字段设计要预留扩展空间。

2.5 报修管理模块

报修模块包含租客提交报修工单、房东查看处理、管理员统计三个环节。工单状态机包括：待处理、处理中、已完成、已关闭。租客提交工单时需要选择报修类型（水、电、燃气、门窗等），填写问题描述并上传图片。房东或管理员接单后更新状态为处理中，处理完成后更新为已完成并填写处理备注。

2.6 数据统计与可视化

管理后台需要有一个数据看板页面，展示系统核心运营指标：房源总数、在租房源数、租客总数、本月租金收入、待处理报修数等。我通过后端统计接口返回聚合数据，前端用ECharts渲染柱状图和折线图。

-- 本月租金收入统计 SELECT SUM(payment_amount) FROM bill WHERE pay_status = 1 AND pay_time >= #{monthStart} AND pay_time <= #{monthEnd}

3. 环境搭建与项目落地实操

这一部分是整套项目能否顺利运行的关键。我见过太多项目代码没问题，但环境配不好导致跑不起来的情况。下面把从零搭建到项目启动的完整流程和版本兼容性注意事项展开细说。

3.1 开发环境版本对照

先给出一套经过验证可直接使用的版本组合：

这里特别强调一下MySQL 8.0和5.7的差异。8.0的驱动类名是com.mysql.cj.jdbc.Driver，5.7用com.mysql.jdbc.Driver也行但现在推荐用cj的那个全驱动。8.0还需要额外指定时区参数serverTimezone=Asia/Shanghai，否则会报时区错误。如果服务器上装的是8.0，连接串要写成：

spring: datasource: url: jdbc:mysql://localhost:3306/house_rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

3.2 项目结构规划

拿到一个新的全栈项目，第一件事不是急着写代码，而是规划目录结构。我习惯把后端项目按如下方式分包：

com.example.houserent ├── config # 配置类（跨域、拦截器等） ├── controller # 接口层 ├── service # 业务层 + 实现类 ├── mapper # MyBatis映射接口 ├── entity # 实体类 ├── dto # 数据传输对象 ├── common # 公共类（统一返回结果、异常处理等） └── utils # 工具类（JWT、日期处理等）

前端项目结构按照Vue脚手架约定，pages或views目录下按模块分文件夹：login、home、house、lease、bill、repair、admin等，公共组件放在components目录，请求封装放在utils/request.js。

3.3 后端核心配置与代码实现

后端最核心的是application.yml配置和MyBatis的Mapper层实现。配置方面有一个容易被忽视的点：mybatis的map-underscore-to-camel-case参数。如果数据库字段用下划线命名（如house_title），实体类属性用驼峰命名（houseTitle），必须开启这个参数才能自动映射，否则查询结果会出现大量null值。

mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.houserent.entity configuration: map-underscore-to-camel-case: true

Mapper层有两种实现方式：注解SQL和XML映射。简单的增删改可以用注解，但多表关联查询、动态条件查询建议用XML，可读性和可维护性更好。

房源列表的分页条件查询是典型例子，需要支持按标题模糊搜索、区域筛选、租金区间筛选，还需要join房东表查出房东姓名：

<select id="selectHousePage" resultType="com.example.houserent.entity.House"> SELECT h.*, u.real_name AS ownerName FROM house h LEFT JOIN user u ON h.owner_id = u.id <where> <if test="title != null and title != ''"> AND h.title LIKE CONCAT('%', #{title}, '%') </if> <if test="district != null and district != ''"> AND h.district = #{district} </if> <if test="minPrice != null"> AND h.rent >= #{minPrice} </if> <if test="maxPrice != null"> AND h.rent &lt;= #{maxPrice} </if> AND h.status = 1 </where> ORDER BY h.create_time DESC LIMIT #{offset}, #{pageSize} </select>

分页实现我用的PageHelper插件，拦截器自动生成COUNT查询和LIMIT语句，非常省事。引入方式：在pom.xml添加pagehelper-spring-boot-starter依赖，然后在配置类里声明分页插件。

3.4 前端核心页面实现

前端最核心的封装是request.js请求工具。我基于axios封装了统一的请求实例，配置了baseURL，通过拦截器统一处理token注入和响应解包：

// 前端请求封装核心代码 const request = axios.create({ baseURL: 'http://localhost:8080', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use(res => { const data = res.data if (data.code !== 200) { Message.error(data.message) return Promise.reject(new Error(data.message)) } return data.data }, err => { if (err.response && err.response.status === 401) { router.push('/login') } return Promise.reject(err) })

路由守卫方面，通过router.beforeEach判断用户是否已登录，未登录访问需要鉴权的页面时自动跳转到登录页。这里还有一个小细节：根据用户角色动态过滤路由菜单。我的做法是登录后从后端获取用户信息和角色，通过菜单数组的v-if判断不同角色能看到的菜单项，简单且有效。

3.5 前后端联调与跨域处理

联调阶段最容易踩的坑是跨域问题。前端页面跑在9528端口，后端接口跑在8080端口，浏览器会拦截跨域请求。解决方法有两种：后端配置CORS过滤器，或者前端配置代理。

我推荐后端配置全局CORS，这样上线部署时只要后端口不变，前端请求就不用再改。使用SpringBoot的@CrossOrigin注解或WebMvcConfigurer实现：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(Registry registry) { registry.addMapping("/**") .allowedOrigins("http://localhost:9528") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true); } }

注意一个细节：如果使用了拦截器校验token，要确保OPTIONS预检请求在拦截器中直接放行，否则浏览器CORS预检会被拦截器挡住，导致真正的请求发不出去。

4. 项目部署与常见问题排查

项目跑通只是第一步，能把项目打包部署上线、能在遇到Bug时快速定位问题，才是真正拉开发者差距的地方。

4.1 本地打包部署流程

后端打包之前，要确认application.yml中的配置是否为生产环境配置。注意把数据库连接地址、用户名密码改成目标服务器的对应配置。然后执行Maven打包命令：

mvn clean package -DskipTests

打包成功后，target目录下会生成一个jar文件，通过java -jar命令启动：

java -jar house-rent.jar

如果服务器内存有限，可以调整JVM参数限制内存占用：

java -Xms256m -Xmx512m -jar house-rent.jar

前端打包执行npm run build，生成dist目录，里面是静态资源文件。dist目录可以直接部署到Nginx的html目录下。这里涉及一个前端静态资源的配置细节：如果IP加端口直接访问，需要把Vue的router改成hash模式，这样刷新页面时就不会出现404。如果部署到子路径，还需要在vue.config.js中配置publicPath。

4.2 数据库中遇到的各种问题

这类项目实践下来，数据库相关的问题占比超过一半。我罗列几个高频问题：

第一个是时区问题。连接MySQL 8.0时如果不在JDBC URL中指定serverTimezone=Asia/Shanghai，查询日期时间字段会报错或显示不正常，具体报错是CST时区识别问题。

第二个是中文乱码问题。建库时要明确指定utf8mb4字符集：

CREATE DATABASE house_rental DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4相比utf8能存储emoji等特殊字符，是8.0时代推荐的做法。

第三个是数据导入问题。如果从别人那里拿到sql文件，使用source命令导入时可能因为文件太大报错，或者因为sql文件里包含时间字段导致导入格式异常。推荐用Navicat或DataGrip的导入功能，比命令行稳妥得多。

4.3 前后端联调时的接口问题排查

接口联调阶段，我建议后端开发一定要统一返回格式。我定义了Result类，包含code、message、data三个字段，成功返回code=200，业务异常返回code=500，未登录返回code=401。前端统一解包后在业务逻辑中不用再单独判断状态。

遇到前端拿不到数据的情况，按照从内向外的顺序排查。先在浏览器控制台的Network面板确认接口是否真的发出了请求、请求URL是否正确。然后看响应状态码和响应体内容，是401需要重新登录，还是500说明后端抛异常了。后端的控制台会打印异常堆栈，一般通过堆栈信息就能定位到是SQL写错了还是空指针了。

一个常见的联调问题是IDEA和VSCode两个工具同时运行时，前端axios请求看起来正常，但后端接口没有收到。此时先检查是否因端口占用导致后端服务根本没启动成功，再检查跨域配置是否生效。

4.4 JWT Token过期与刷新机制

JWT登录模式有一个比较隐蔽的问题：token过期后前端仍停留在页面，用户点击操作时才弹401，体验很差。我的解决思路：前端在axios响应拦截器里处理401时，跳转到登录页并提示"登录已过期，请重新登录"。同时在后端登录接口设置合理过期时间（我设置的24小时），这个时长对于毕设演示和中小型系统是够用的。

如果需要更完善的方案，可以考虑refresh token机制：登录时同时返回accessToken和refreshToken，accessToken短期有效（如1小时），过期后通过refreshToken换取新的accessToken，用户无感续期。

5. 系统测试与性能优化经验

项目开发完成后，测试和质量优化是让项目达到"能用于毕业设计答辩展示"标准的关键一步。这部分我分享一些实际测试中发现的典型问题和优化手段。

5.1 功能测试要点与边界情况

我按照模块逐项做了功能测试，重点覆盖核心业务场景。测试时要特别关注边界情况：重复申请租房、同时提交多个房源、异常输入等。

以用户注册为例，编写的测试用例包括：用户名已存在的提示、密码长度校验、两次密码是否一致、邮箱格式校验。注册逻辑中需要先查询用户名是否已存在，再插入新用户。一个常见的Bug是前端传密码时做了加密，后端收到的密码密文长度超出数据库字段长度导致报错，解决方案是在后端把密码进行MD5加密后存入数据库，字段长度设成32或64。

业务逻辑中的异常场景要重点测试，比如银行卡支付模拟时余额不足、房源下架时已有租约怎么办。这些问题在开发时容易忽略，测试时会暴露出来。我的建议是列出每个模块的异常清单，逐一测试并补充代码处理。

5.2 页面加载性能优化

房源的图片列表如果一次性加载太多，页面响应会明显变慢。优化的手段是前端图片懒加载，Vue生态可以直接用v-lazy指令或懒加载插件实现，当图片进入视区时才请求加载。

另一个优化点在后端接口层面的数据量控制。房源列表接口默认每页10条数据，前端分页组件每切换一页重新请求接口，避免一次性查出全部数据造成接口响应延迟和页面卡顿。

数据库层面的优化主要是为高频查询字段建立索引。比如user表的username字段、house表的status和district字段、lease表的house_id字段，都建议加上索引。在数据量超过十万条的时候，索引能带来数量级的查询性能提升。

5.3 并发控制与数据一致性

租赁系统存在并发问题，比如多个租客同时发起同一次签约请求。我在处理签约接口时采用数据库乐观锁方案：在lease表增加version字段，创建租约时先查询version，更新时带上version条件。

更简单有效的做法是采用Redis分布式锁，在关键事务中锁住房源id，等事务完成后再释放。但这个方案在毕设项目中可以不做，因为单机部署不涉及真正的并发流量。不过建议在文档中提一下，面试时被问到并发问题时能展现出思考深度。

6. 项目亮点与经验总结

整套系统开发完成的收获非常大。从技术层面看，把SpringBoot、MyBatis、MySQL、Vue、Element UI串联起来，对全栈开发有了完整的认知。从工程层面看，我体会最深的是项目结构设计的重要性，如果前期建立清晰的模块边界，后续的开发和测试会顺很多。

6.1 系统功能亮点

房屋租赁管理系统最核心的亮点功能有三块。第一个是租约到期自动提醒机制：系统每日定时任务扫描租约截止日期，提前30天、15天、7天向房东和租客发送站内提醒消息。这个功能在毕设中很加分，展示了定时任务和业务逻辑的结合能力。实现方式是在SpringBoot中通过@Scheduled注解每天凌晨执行一次扫描任务。

第二个是数据看板的可视化展示：管理员首页展示房源分布图、各区域租金行情、月度收入趋势。这块是加分项，能直观呈现系统的数据价值。

第三个是角色的精细化权限控制：用户、房东、管理员三端各有独立空间。权限控制和业务数据隔离是这类管理系统躲不开的关键点，能做好说明对业务理解到位了。

6.2 开发过程的重要经验

回顾整个开发过程，有几个经验我觉得对后来者特别有参考价值。

第一，先画流程图再写代码。动手写代码之前，一定要把核心业务流程图梳理清楚。比如租房流程是：看房->签约->生成账单->缴费->入住->报修->退房清算，这个流程想明白之前，直接写代码很容易走到一半发现逻辑对不上，然后大改。

第二，代码要写注释但不要写废话。每个方法上写清楚业务含义，比如"根据条件分页查询房源列表，支持按区域和租金筛选"，而不是"查询房源"。好的注释能在答辩时帮你快速回忆起代码逻辑。

第三，善用日志定位问题。在关键业务节点打日志是个好习惯，比如支付流程、租约创建流程。出现异常时，日志能帮你在几分钟内定位问题，而靠断点调试可能花上一个小时。

第四，不要把前端开发当成后端的附属工作。我在项目后期才发现，前端页面的交互流畅度和颜值对最终效果呈现起到决定性作用。一个操作顺手、界面整洁的系统，比功能堆砌但按钮难找的系统给人的整体感受好得多。

7. 基于这套系统的后续扩展思路

项目做完之后，我思考了几个可以继续深化的扩展方向。这些思路写在文档里能体现项目的成长空间，如果有精力也可以部分实现。

第一个方向是引入Redis缓存热门房源数据，减轻数据库压力。实现上比较简单，查询房源详情时把热点数据缓存到Redis，设置过期时间，写入时更新缓存。这一改动在文档里描述清楚就能体现出对性能优化的思考。

第二个方向是开发移动端适配版本。当前Vue2项目可以实现移动端的响应式适配，但用uni-app框架基于现有业务逻辑重新开发移动端小程序版也是一条常见路径，可以充分复用现有后端接口。

第三个方向是引入消息通知机制，当租约即将到期、账单生成时通过短信或邮件通知用户。系统可以接入邮件服务，在租约到期提醒、账单生成通知等场景下自动推送邮件。

第四个方向是完善支付模块，对接真实的第三方支付API。当然在毕设阶段模拟支付已经足够，但对接支付接口后会暴露出更多细节：支付回调、订单状态一致性等。这也是面试时可以聊得很深的话题。

如果后续有时间，我计划先做缓存优化和消息通知这两个方向，因为它们是当前系统最薄弱的两个环节，优化后对性能和用户体验的提升最明显。

这次项目做完，最大的感受是：技术栈其实都是成熟的东西，真正的难点在于把业务逻辑理清楚，把所有细节串联起来。每一个模块单独拿出来都不难，难的是把它做成一个真正能跑的、没有明显Bug的、用户愿意用的完整系统。希望这篇记录能给正在做类似项目的朋友一些启发，少走一点弯路。