做全栈项目最怕的不是功能多复杂而是业务逻辑理不清、代码写到一半自己都看不懂。这套“小型房屋租赁系统”用Spring Boot做后端、Vue做前端源码、数据库脚本和文档全都齐了对一个想练手全栈、或者拿去做课程设计的人来说是个很合适的参考样本。这篇文章就从业务拆解、技术选型、实际搭建、踩坑记录四个方向把整个系统从头到尾捋一遍。不管是想直接跑起来看效果还是打算在此基础上做二次开发应该都能用得上。1. 先拆业务房屋租赁系统到底在管什么1.1 租赁场景里的三类角色和核心流程写代码之前得先搞清楚一个问题房屋租赁系统的使用者到底是谁。很多人一上来就画ER图、建表结果做到一半发现业务场景没想清楚返工成本很高。这套小型租赁系统的定位其实很清晰就是服务典型的房东-租客场景。房东发布房源租客浏览房源、发起预约和签约管理员做审核和统计。整个系统围绕一条主线展开房源从录入到出租、再到退租的完整生命周期管理。具体来说有三个角色管理员负责房源审核、用户管理、订单监控是整个系统数据规则的监督者房东发布房源、管理自己名下的房源状态、查看订单和收入租客搜索房源、查看详情、提交预订、签约入住这个角色设计在小型系统里是合理的它没有引入经纪人、合同仲裁这种复杂的中间角色降低了权限管理的复杂度。权限控制用简单的角色字段区分一个用户登录后根据角色渲染不同的操作菜单这也符合Spring Boot Vue前后端分离项目的通用做法。一条核心业务流程走下来是这样的房东发布房源管理员审核通过租客在门户端看到房源并发起预订房东确认后生成订单租客签约入住。租赁周期结束后房源状态恢复为可租数据进入历史订单统计。整条链路对应着后端接口的设计顺序也决定了数据库表的关联方式。1.2 功能清单哪些模块是一个都不能少的把业务拆开后功能模块就很好定了。这套系统的功能设计属于典型的“麻雀虽小五脏俱全”覆盖了租赁业务的核心闭环又不至于庞大到失控。系统管理用户管理、角色权限、菜单配置房源管理房源录入、图片上传、价格设置、上下架订单管理预订、签约、退租、支付状态跟踪租客管理租客信息维护、租约历史查询统计报表房源出租率、租金收入汇总这里要注意一点房源图片上传这个功能虽然不起眼但在开发里涉及文件存储路径配置、静态资源映射、前端预览回显是一个小但完整的全栈功能点。功能清单里把它列出来也方便后期扩展OSS云存储。1.3 从业务流程图反推数据表设计业务确定后数据表的设计就有了依据。不需要闭门造车直接从流程里抽数据实体就行。核心表基本是user用户表角色字段区分管理员、房东、租客house房源表包含标题、描述、租金、户型、地址、状态order租赁订单表关联房源和用户记录起止时间、金额、状态comment评价表租客对房源和房东的评价notice公告表管理员发布平台通知这些表之间围绕一个核心逻辑user通过house建立房源关系order同时关联房东、租客和房源形成一条完整的数据链。看数据库脚本时重点看外键和索引特别是house_id和user_id这两个高频查询字段有没有加索引直接影响后面联表查询的速度。2. 技术选型的底层逻辑Spring Boot Vue凭什么是最稳的组合2.1 为什么后端不用SSH或者其他框架说到Java后端有人可能会问为什么不用SSHStruts Spring Hibernate或者纯Servlet而选Spring Boot。原因很简单Spring Boot把SSH时代最痛苦的XML配置全部变成了自动配置一个内嵌Tomcat、一个spring-boot-starter-web依赖就能跑起来一个Web服务开发效率不在一个量级。还有一个很现实的原因Spring Boot的生态太成熟了。做权限有Spring Security做数据库操作有MyBatis-Plus或者Spring Data JPA做接口文档有Swagger/knife4j。这套租赁系统在选型上也用了最常见的组合Spring Boot MyBatis-Plus MySQL JWT。MyBatis-Plus在小型项目里特别实用不用写大量XMLBaseMapper自带增删改查分页查询一个Page对象搞定。对于追求开发效率、又不想写一堆模板代码的场景比原版MyBatis更顺手。我用生活化的方式解释一下Spring Boot相当于一个精装修的房子水电、墙地面、门窗都已经做完了你只需要根据自己的需求摆家具、刷颜色。SSH框架相当于毛坯房从水电改造开始都得自己动手经验丰富的老师傅当然能搞得很好但对大多数项目来说投入产出比太低。2.2 前端选Vue的真正原因渐进式框架的灵活性Vue在中小型管理系统的地位几乎是不动摇的。它最核心的优势在于渐进式——一个简单的页面你可以只引入vue.js当一个模板引擎用当项目变复杂了再搭配Vue Router、Pinia/Vuex做单页应用开发。对这套租赁系统来说前端页面分成两部分面向管理员和房东的后台管理界面以及面向租客的门户页面。门户页面不需要非常复杂的交互Vue的指令系统加组件化开发就能覆盖大部分场景而且Vue生态里的Element UI组件库表格、表单、分页、弹窗都是现成的后台管理页面的开发效率尤其高。还有一个关键点是数据绑定。Vue的双向绑定机制v-model让表单交互变得非常直观租客在房源搜索页输入价格范围页面立即过滤列表这种响应式体验在后端模板引擎时代需要写不少原生JavaScript但Vue里只是一个计算属性的事。前端工程化方面Vite或者Vue CLI搭建的项目自带开发服务器、热更新、代码打包开发体验很舒适部署时npm run build生成静态文件扔给Nginx就能跑。2.3 前后端分离的协作模式与联调要点这套系统是典型的前后端分离结构。后端只提供JSON接口不关心页面渲染前端只消费接口数据不管数据库和服务器逻辑。开发过程中API文档显得尤其重要推荐项目里集成knife4j生成在线接口文档前后端联调时能少扯很多皮。联调过程中最容易出现的问题是字段命名不一致。后端习惯用houseName、createTime这种驼峰命名前端能不能直接用取决于后端的JSON序列化配置。建议在Spring Boot的配置里统一设置spring.jackson.property-naming-strategy或者干脆约定所有接口字段都用驼峰命名前端不额外做字段转换这样能省掉一层麻烦的适配。3. 从骨架到血肉这套系统的搭建全过程3.1 项目骨架后端工程结构怎么看拿到源码后先别急着跑起来先花十分钟看一下目录结构。好的工程结构会让人一目了然知道哪个类负责什么功能。标准的Spring Boot分包方式在这套项目里体现得很清晰com.example.rental ├── controller // 接收请求返回响应 ├── service // 业务逻辑层 ├── mapper // 数据访问层MyBatis-Plus接口 ├── entity // 数据库实体类 ├── config // 配置类拦截器、跨域配置 ├── utils // 工具类JWT工具、响应封装 └── common // 通用返回结果、异常处理看代码的建议从controller层入手因为Controller是所有请求的入口一个HouseController对应房源管理所有接口你能直观看到系统提供了哪些功能。然后顺着Controller - Service - Mapper这条调用链往下看就能搞懂一个请求从接收到入库的完整过程。写后端代码时有个不太容易注意但很重要的习惯就是统一返回结果格式。这套项目里通常会有一个Result类code、message、data三个字段所有的接口都返回这个格式。好处是前端拿到响应后统一处理不需要每个接口单独判断成功失败。3.2 前端页面Vue项目的目录与组件划分前端部分的目录结构也很有代表性最适合拿来练手观摩src ├── api // 接口请求封装 ├── router // 路由配置 ├── views // 页面组件 ├── components // 公共组件 ├── store // 状态管理Pinia/Vuex └── utils // 工具函数axios封装这套结构在前端项目里几乎成了事实标准。接口请求单独放在api目录每个页面模块对应一个文件比如house.js里封装房源的新增、查询、上下架接口请求。写页面时只关心怎么调用接口函数不用在业务代码里到处写axios.get的完整地址。路由配置里需要重点看的是登录鉴权相关的逻辑。通常会有全局前置守卫判断token存不存在不存在就跳转登录页。这也是前后端分离项目里最常见的交互逻辑之一。组件划分讲究复用性比如房源卡片组件在租客门户的列表页可以用在收藏列表页也能用抽象为一个公共组件后两处共用一套模板和样式。Vue的组件化思想在这类项目里体现得很充分。3.3 数据库初始化从SQL脚本到本地环境跑通把数据库这块准备好项目基本就能活起来了。SQL脚本里包含了建库、建表、初始数据插入在MySQL中直接执行就行。有几类初始数据值得关注管理员账号通常是admin/admin123测试用的房东和租客账号几套房源样例数据方便页面展示字典数据比如房源类型整租、合租、订单状态等推荐在SQL脚本里把时间字段都设计成datetime类型而不要用timestamp避免MySQL服务器时区问题导致的数据错乱。这套系统如果用的是MySQL 8.0建表字符集和排序规则要注意设置utf8mb4和utf8mb4_general_ci不然中文数据可能会出乱码查询排序也可能不符合预期。数据库脚本还原后打开Spring Boot项目改一下application.yml里的数据库连接信息账号、密码、数据库名启动后端服务再在前端目录执行npm install和npm run serve全套系统就能在浏览器里访问了。3.4 核心功能实现细节以订单状态流转为例整个系统里最容易写乱的就是订单状态管理。一套租赁系统订单状态通常有待支付、已完成、租赁中、已退租、已取消。如果状态字段设计不合理退租功能很容易留坑。推荐的方案是维护一个订单状态字段用数字标识状态。在Service层定义状态流转方法比如confirmOrder()只有待支付的订单能调用checkoutHouse()只有租赁中状态的订单能调用。通过状态机来限制非法流转而不是在Controller里到处写if (order.getStatus() 1)这种散落的条件判断能让代码好维护得多。做之前可能觉得这属于过度设计但一旦订单状态多了散落的逻辑判断会让你改一个状态对应关系时翻遍整个项目代码。集中管理状态流转是这类业务系统的核心经验之一。4. 实操复盘常见问题与排查技巧实录4.1 跨域问题不配置就白屏的经典坑前后端分离项目第一大概率遇到的问题就是跨域。浏览器默认不允许一个源协议、域名、端口任一不同的Web应用访问另一个源的资源前端在localhost:8080后端在localhost:8081直接请求就会报CORS错误。解决方案有好几种最直接的是在后端写一个CORS配置类实现WebMvcConfigurer接口重写addCorsMappings方法指定允许的路径、来源和请求方法。也有项目用拦截器设置响应头或者在Spring Boot里加CrossOrigin注解但全局配置类的方式一劳永逸不用在每个Controller上重复加注解。排查这个问题有个小技巧在浏览器F12开发者工具里的Console面板看到报错信息里带CORS或Access-Control-Allow-Origin字样基本就能锁定是跨域问题。如果接口响应能拿到数据但页面上不显示也要优先怀疑是不是请求被浏览器拦截了。4.2 前端请求401JWT Token过期与拦截器逻辑登录后访问需要权限的接口如果返回401通常有两种情况Token过期或者请求没有正确携带Token。前者需要前端在Token过期后跳转登录页重新登录后者通常是因为axios请求拦截器里没有取到存储的Token。建议团队的实践是登录成功后将Token存储在localStorage里同时用Vuex/Pinia把它存一份做全局的状态管理。axios的请求拦截器从localStorage取Token并设置到请求头Authorization字段响应拦截器统一处理401错误跳转登录页并提示用户登录状态过期。Spring Boot后端的登录鉴权一般通过拦截器或Spring Security实现。如果是简单的JWT拦截器要注意在WebMvcConfig里排除登录接口和房源列表等公开接口路径不然连登录验证都做不了。4.3 数据格式问题日期和金额的两个精细坑日期格式化是联调时很常见的返工点。后端返回的LocalDateTime默认格式是2024-01-15T10:30:00欧美风格前端显示得转换。统一解决方案是配置JsonFormat(pattern yyyy-MM-dd HH:mm:ss)或者全局配置Jackson的格式。金额字段最好用BigDecimal不要用double或float不然计算精度误差会让你在租金汇总时崩溃。这两个坑在测试时容易被忽略因为页面显示不出来明显报错但到了统计报表功能金额对不上、日期排序不对排查起来就很花时间。协议好之后写接口时顺手就把格式处理掉能省很多后续麻烦。4.4 图片上传后访问404静态资源路径的正确配置房源图片上传成功但前端访问图片地址时404这是文件存储类功能最常见的问题。原因是Spring Boot默认的静态资源路径只有classpath:/static/、classpath:/public/这些目录你上传到本地磁盘的图片并不在这些路径下。解决办法是自定义一个WebMvcConfigurer添加资源映射Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadPath /); }这样配置以后图片存放目录和项目本身解耦重启服务不会丢失上传的文件。做这类功能有个心得上传的文件名不要用原始文件名用一个UUID或时间戳生成新文件名避免中文文件名和文件名冲突带来的一堆问题。5. 这套系统还能怎么玩二次开发的实用方向5.1 从单体到微服务什么时候不需要升级很多同学看到Spring Boot项目第一反应是它不够“高大上”想往Spring Cloud微服务方向改造。但要泼一盆冷水小型租赁系统这个业务规模和团队规模微服务化只会增加部署和运维成本不会带来实际收益。什么时候才真正需要拆微服务当系统里有独立的模块存在完全不同的流量模型和扩展需求时比如独立的支付服务、独立的短信通知服务。对这套租赁系统而言单体架构完全够用拆成微服务属于纯纯的过度设计。但有一个值得做的演进方向把业务模块的边界整理得更清晰。比如order模块的Service只依赖自己的Mapper不要跨模块调其他模块的Mapper模块之间通过接口通信。这样即使未来需要拆服务改动成本也会小很多。5.2 功能扩展路径从核心到周边的三个方向租房系统的核心闭环做完之后可以考虑三个方向的扩展第一个方向是支付接入。对接一个真实支付平台把状态从“待支付”推进到“已支付”。这一步能把支付回调、异步通知、对账这些真实的工程问题带出来再小的项目只要接支付复杂度会立刻上一个台阶。第二个方向是消息通知。当房东发布房源、租客提交订单时系统自动发送短信或邮件。这涉及异步消息队列或定时任务的引入也是一个很好的学习点。第三个方向是数据可视化。目前系统的统计报表可能只是表格和简单数字可以引入ECharts进行图表展示房源出租率、月度租金趋势用图表呈现视觉体验和表达效率会提升不少。5.3 部署上线从本地运行到服务器发布开发完的系统不能只在本地跑还得过部署这一关。常规流程是前端npm run build生成dist目录用Nginx托管同时配置反向代理将/api开头的请求转发到后端服务端口。后端打包成JAR包在服务器上nohup java -jar启动或者用systemd做一个服务管理配置省心很多进程挂了还能自动重启。数据库迁移时直接执行SQL脚本注意生产环境的账号密码不要写在配置文件里用环境变量或者配置中心管理。这一整套部署流程走一遍一个全栈项目才算闭环。6. 聊聊我做完这套系统的真实感受最后说几句做全栈项目的亲身体会。拿到一套完整源码后不要急着跑也不要大改特改先原样运行起来把每个功能点都点到感受一下一个完成的业务系统操作流程是什么样的。然后选几个你最有感觉的模块深挖代码搞懂每一步的来龙去脉再动手修改。整个学习过程下来最明显的收获是对业务建模的感觉。技术只是手段真正拉开差距的是你对业务需求的理解和转换能力怎么把一套租赁流程拆成合理的数据表和接口怎么处理订单状态这种容易出错的状态流转这些才是最有价值的部分。如果只让我推荐一个地方的代码来精读我推荐订单模块因为它涉及的表最多、状态最复杂、前后端数据传输的字段也最长。搞懂了订单这个模块你基本上就搞懂了这套系统最核心的工程难点。在自己动手改代码的阶段建议尝试这样的路径先给现有系统增加一个简单功能比如房东可以录入房源配套的设施信息顺着现有代码风格把这个功能串起来这是真正检验理解程度的有效方式。做完一个功能再回头看这套系统的设计你一定会有完全不同的理解。