做了大半个月终于把基于SpringBootVue的房屋租赁管理系统完整跑通了。这几天趁热打铁把整个项目的开发思路、核心模块、关键代码和踩坑记录整理出来给准备做毕设或者正在学习全栈开发的朋友一个参考。这个项目我用的技术栈是SpringBoot MyBatis MySQL做后端Vue Element UI做前端涵盖了房屋租赁业务中的房源管理、租约合同、账单缴费、报修管理等核心环节。整套系统从前端页面到后端接口再到数据库设计都是完整可运行的不是那种只有几个demo页面的半成品。1. 项目整体设计与技术选型先聊聊技术选型的问题。我见过不少同学一上来就纠结用SSM还是SpringBoot用JSP还是前后端分离结果纠结了半个月代码还没写一行。其实对于房屋租赁管理系统这种典型的管理信息系统选型逻辑非常清晰SpringBoot负责快速搭建后端服务MyBatis负责数据库操作MySQL存数据Vue做前端页面这套组合是当前JavaWeb领域最成熟、资料最多、遇到问题最容易搜到解决方案的搭配。1.1 为什么选择SpringBoot而非传统SSM传统SSMSpring 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 用户认证与角色权限管理用户模块是系统的入口涉及注册、登录、角色识别三个环节。系统内置三种角色管理员、房东出租方、租客承租方不同角色登录后看到的菜单和操作权限完全不同。登录逻辑我用的技术方案是JWTJSON 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字段的唯一索引在多个有效状态时不友好。最终我采用了更简单的方案创建租约时先查询该房源是否存在状态为有效status1的租约如果存在则拒绝。-- 创建租约前检查房源占用情况 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 开发环境版本对照先给出一套经过验证可直接使用的版本组合组件版本说明JDK1.8稳定且兼容性好Maven3.6依赖管理SpringBoot2.7.18亲测稳定MyBatis2.xSpringBoot对应starterMySQL5.7 或 8.0两者均可Vue CLI4.5.x创建Vue2项目Element UI2.15.x适配Vue2Node.js14.x 或 16.x版本不宜过高这里特别强调一下MySQL 8.0和5.7的差异。8.0的驱动类名是com.mysql.cj.jdbc.Driver5.7用com.mysql.jdbc.Driver也行但现在推荐用cj的那个全驱动。8.0还需要额外指定时区参数serverTimezoneAsia/Shanghai否则会报时区错误。如果服务器上装的是8.0连接串要写成spring: datasource: url: jdbc:mysql://localhost:3306/house_rental?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver3.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: trueMapper层有两种实现方式注解SQL和XML映射。简单的增删改可以用注解但多表关联查询、动态条件查询建议用XML可读性和可维护性更好。房源列表的分页条件查询是典型例子需要支持按标题模糊搜索、区域筛选、租金区间筛选还需要join房东表查出房东姓名select idselectHousePage resultTypecom.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 testtitle ! null and title ! AND h.title LIKE CONCAT(%, #{title}, %) /if if testdistrict ! null and district ! AND h.district #{district} /if if testminPrice ! null AND h.rent #{minPrice} /if if testmaxPrice ! 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中指定serverTimezoneAsia/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三个字段成功返回code200业务异常返回code500未登录返回code401。前端统一解包后在业务逻辑中不用再单独判断状态。遇到前端拿不到数据的情况按照从内向外的顺序排查。先在浏览器控制台的Network面板确认接口是否真的发出了请求、请求URL是否正确。然后看响应状态码和响应体内容是401需要重新登录还是500说明后端抛异常了。后端的控制台会打印异常堆栈一般通过堆栈信息就能定位到是SQL写错了还是空指针了。一个常见的联调问题是IDEA和VSCode两个工具同时运行时前端axios请求看起来正常但后端接口没有收到。此时先检查是否因端口占用导致后端服务根本没启动成功再检查跨域配置是否生效。4.4 JWT Token过期与刷新机制JWT登录模式有一个比较隐蔽的问题token过期后前端仍停留在页面用户点击操作时才弹401体验很差。我的解决思路前端在axios响应拦截器里处理401时跳转到登录页并提示登录已过期请重新登录。同时在后端登录接口设置合理过期时间我设置的24小时这个时长对于毕设演示和中小型系统是够用的。如果需要更完善的方案可以考虑refresh token机制登录时同时返回accessToken和refreshTokenaccessToken短期有效如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的、用户愿意用的完整系统。希望这篇记录能给正在做类似项目的朋友一些启发少走一点弯路。