前后端分离的大学生在线租房平台是这两年出现频率很高的毕设和练手项目。搜索引擎里一搜一大把但很多同学卡在同一个地方源码拿到了环境配不明白数据库导不进去前端代理配错最后跑起来看到的不是登录页而是满屏报错。这篇文章我想换个方式不贴一份所谓的完整源码就完事而是把从技术选型、数据库设计、接口联调到最后部署上线的全过程拆开讲重点讲清楚每一步为什么要这么做。项目本身是SpringBoot Vue MyBatis MySQL的组合前后端分开部署角色覆盖学生租客、房东和管理员三种身份。如果你正打算做类似的租房系统或者刚接手一份源码想让它在本地和服务器上顺利跑起来这篇内容可以直接当作参照。1. 技术栈组合这套开发框架为什么在租房类项目里经久不衰1.1 后端用SpringBoot而不是其他框架的原因我做这个项目时后端基本没犹豫就选了SpringBoot。原因很直接生态成熟坑少资料多。SpringBoot把过去Spring MVC时代繁琐的XML配置全部简化掉了依赖管理交给Maven或Gradle内嵌Tomcat直接让项目变成一个可以独立运行的Jar包。对于在线租房平台这种典型的CRUD加业务状态流转的Web系统单体应用完全够用不需要引入微服务体系给自己增加复杂度。有人会问现在主流不都是Spring Cloud那套微服务吗怎么还在用单体租房平台的业务量级和团队规模摆在那里单体架构能把开发、测试、部署的成本压到最低。真到了需要拆分的时候按用户、房源、订单这几个域去拆也不晚。SpringBoot的单体结构反而让整个项目显得干净评审老师或者面试官问起来也好解释。1.2 Vue负责的界面层与前后端分离的本质前端我选了Vue配合Vue Router做页面路由、Vuex或者Pinia做状态管理再搭配Element Plus这一套组件库。选Vue的很大一部分原因是它对国内开发者太友好了中文文档齐全组件生态完善学习曲线比React要平缓不少。前后端分离这个概念很多人理解成前端一套代码后端一套代码。这没说错但不完整。真正的分离是前端只负责渲染和交互通过Ajax请求后端接口拿JSON数据后端只负责处理业务逻辑和读写数据库不关心页面长什么样。两边用HTTP协议沟通接口就是契约。开发过程中只要接口文档定义清楚了前端和后端可以并行开工不必等对方完成。部署上两者也完全解耦前端构建出静态文件扔给Nginx托管后端打成Jar包独立运行。这种结构放在在线租房平台里最直观的体验就是页面响应速度快因为静态资源由Nginx直接返回后端只处理真正的业务请求。1.3 MyBatis MySQL数据层选型理由与配合方式数据层我用了MyBatis和MySQL。有些项目喜欢用MyBatis-Plus确实能省不少代码基础的增删改查不用手写SQL。但我做这个项目刻意用了原生MyBatis原因是租房平台的查询逻辑不算简单房源搜索需要多条件组合、排序需要动态拼接、统计报表要写聚合SQL。MyBatis的动态SQL能力在应付这种场景时非常顺手而且SQL是自己写的出问题时一眼就能定位。MySQL的选择没什么悬念。它是开源数据库里最普及的关系型数据库事务支持靠谱性能在单机场景下完全够用校园项目甚至中小型商用系统的数据量都不会构成压力。MyBatis和MySQL的配合方式很直接MyBatis负责把Java对象和SQL语句映射起来SQL写在Mapper.xml文件里数据库连接用Druid或者HikariCP连接池管理。对比维度SpringBoot MyBatisSpringBoot JPA复杂查询控制力SQL自己写完全可控需要折腾Specification或注解SQL上手难度需要会写SQL门槛略高简单CRUD极快SQL调优路径直接看执行计划需要理解框架生成的语句适合场景业务规则清晰、查询复杂快速原型、领域模型驱动对租房平台这类业务来说SpringBoot MyBatis MySQL是性价比最高的组合这也是它成为经典毕设四件套的原因。2. 三种角色与业务闭环从账号注册到房源成交的完整链路2.1 用户角色划分与功能矩阵在线租房平台最核心的价值是撮合房东和租客。我的项目里把用户分成了三种角色注册时通过下拉框选择后端用角色字段区分权限。学生租客端的核心功能是找房登录注册、按城市区域价格搜索房源、查看房源详情和图片、收藏意向房源、提交看房预约、下单签约租房订单。房东端负责供给端可以发布房源、管理自己名下的房源上下架、查看和处理租客预约、确认订单并生成合同信息。管理员是平台的裁判负责用户管理、房源审核、公告发布和基础数据统计。这三种角色形成了完整的业务闭环。没有管理员审核的房源平台很容易被广告和虚假房源淹没没有预约和订单流程租客和房东之间就停留在看个联系方式自己聊的原始状态谈不成真正意义上的平台交易。2.2 权限控制的实现思路JWT与路由守卫多角色系统最怕权限漏洞。这个项目我用的是JWT 后端拦截器 前端路由守卫的组合方案。用户登录成功后后端根据用户Id和角色生成一个带有效期的JWT字符串返回给前端。前端把Token存到localStorage里每次请求在Axios拦截器中自动带上Authorization请求头。后端写一个拦截器对除登录注册外的所有接口校验Token解析出用户信息后放到ThreadLocal里这样后续业务代码随时能拿到当前登录用户。前端这边的路由守卫也很关键。Vue Router的beforeEach钩子会检查目标路由的meta信息如果页面要求登录但没有Token直接重定向到登录页。管理员的页面还会多校验一次角色普通用户即使手动输入管理路径也会被拦下来。下面是一个简化版的路由守卫写法核心逻辑就这几行router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else if (to.meta.role localStorage.getItem(role) ! to.meta.role) { next(/403) } else { next() } })后端的Service层还会再做一次数据权限校验。房东只能修改和删除自己发布的房源订单操作必须校验订单归属人。前后端双重校验这是实打实的安全习惯不能省。2.3 房源审核机制与业务状态机做租房平台之前我想过一个问题房东随便发一套不存在的房子怎么办所以房源表里必须有一个审核状态字段我设计成了0待审核、1已上架、2已下架、3审核不通过四种状态。房东提交房源后状态是0租客端搜不到只有管理员在后台能看到。管理员审核通过变成1房源才进入公开展示列表。房东可以主动下架房源变成2。如果审核被判不通过状态是3房东需要修改后重新提交。订单模块也有自己的状态流转。预约看房后记录状态从未处理到已联系、已完成。正式下单后订单状态包含待支付、已支付、已完成、已取消。状态多的模块我会在Java里定义一个枚举类来管理Java和数据库里存的都是数字展示名由前端根据状态值映射成文本。这样一来逻辑清晰后续如果要增加新状态只需要在枚举类里加一个值。3. 数据库设计用8张核心表支撑起整个租房平台3.1 数据模型概览与E-R关系说明数据库设计好坏直接决定后续开发是顺风顺水还是到处打补丁。我在建表之前先在纸上画了实体关系图梳理下来核心表一共8张用户表、房源表、房源图片表、收藏表、看房预约表、租赁订单表、系统公告表、留言反馈表。用户表和房源表是一对多的关系一个房东可以发布多套房源。房源表和图片表也是一对多因为一套房子会有封面图、卧室图、客厅图等多张照片。收藏表、预约表、订单表本质上都是不同场景下的关联表分别把用户和房源以不同目的连接起来。我在建表的时候特意没有加物理外键。原因很实际物理外键会让表之间的耦合变得很重插入数据时必须按顺序批量导入也麻烦。更关键的是租房平台的房源会做逻辑删除如果外键存在删除和改状态时处处受限制。用逻辑外键也就是业务字段保存关联Id配合代码层面的约束灵活度更高性能和可维护性都更好。3.2 核心表的字段级设计详解我把核心字段设计列出来直接看表结构比空谈理论要直观得多。用户表 user字段类型说明idbigint主键自增usernamevarchar(50)登录名唯一索引passwordvarchar(100)BCrypt加密后的密码nicknamevarchar(50)昵称phonevarchar(20)手机号avatarvarchar(255)头像图片路径roletinyint1学生 2房东 3管理员statustinyint1正常 0禁用create_timedatetime注册时间房源表 house字段类型说明idbigint主键user_idbigint房东用户Idtitlevarchar(100)标题covervarchar(255)封面图路径areadecimal(10,2)面积单位平方米pricedecimal(10,2)月租金rent_typetinyint1整租 2合租cityvarchar(30)城市districtvarchar(30)区域addressvarchar(255)详细地址descriptiontext房源描述statustinyint0待审核 1已上架 2已下架 3审核不通过金额字段必须用Decimal类型不能用Float或者Double二进制的浮点数在金额运算中会丢精度这属于基础常识但特别容易踩。状态字段统一用Tinyint存数字而不是字符省空间查询也快。房源图片表 house_image 单独建表的原因是图片数量不确定一套房源可能三五张也可能十来张。如果全部拼进房源表里字段会非常僵化。单独建表后查询时按house_id查全部图片按sort字段排好序主图用is_main字段或直接用表里第一条记录。收藏表 favorite 设计了一个唯一索引组合字段是user_id和house_id。这样同一个用户对同一套房子的收藏记录在数据库层面就不会出现重复不需要在代码里做额外的存在性判断安全性更高。3.3 索引与查询优化让列表页和搜索不卡顿在线租房平台查询压力最大的场景是房源列表页和搜索功能。用户按照城市、区域、租金范围、租赁方式去筛房源如果表里没有合适的索引全表扫一遍房源数据量稍微上来页面就会明显变慢。房源表的索引我做了三个status和city的联合索引因为筛选某个城市的已上架房源是非常高频的查询价格字段单独建索引方便按租金排序和范围筛选user_id上建普通索引房东查询自己名下房源时会用到。除了索引列表查询还有个关键优化上架状态的房源每次都要查但审核中、已下架的数据不该出现在租客端的结果集里。SQL里始终带上status 1这个条件配合联合索引就有很好的效果。有一类常见错误是在SQL里写类似 WHERE status 1 OR city ? 这样的条件OR一旦出现索引优化器往往会放弃最优执行计划。我会习惯性地把OR拆成递归查询或者改成IN这个细节在做列表页时最好留意一下。4. 前后端联调实战跨域、精度、日期与图片上传的四个坎4.1 跨域问题的两种解法与各自适用场景前后端分离项目跑起来之后遇到的第一个大问题多半是跨域。浏览器的同源策略规定页面和接口的协议、域名、端口只要有一个不一致Ajax请求就会被拦截。本地开发时前端在Vite的5173端口起服务后端在8080端口不一致天然跨域。我的开发环境解决方案是配置Vite的Proxy代理前端请求统一走 /api 前缀Vite把它转发到后端的8080端口。浏览器始终认为自己在请求同一个源的地址根本不会触发跨域。// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }生产环境里的解法就交给Nginx反向代理。前端静态文件和后端接口都由Nginx对外统一暴露同样是同源访问。很多人会在后端写一个CORS全局配置允许所有来源访问开发时省事但上线后等于给别的网站留了调用自己接口的口子安全隐患放在那里。我用代理方案为主后端CORS只配置成允许指定的前端域名两边的优势都拿到。4.2 主键精度丢失与日期序列化的统一处理联调过程中最容易莫名出bug的是数据库主键从后端传到前端后变了。MySQL的BIGINT类型是64位整数而JavaScript的Number类型只能安全表示53位以内的整数。当主键值超过这个范围前端的Id最后几位就会变成0。这个问题在自增主键数据量少时看不出来一旦主键增长到千万级或者用了雪花算法生成分布式Id就会频繁出现明明存在记录却改不动、删不掉的情况。解决方案是在后端统一把Long类型序列化成字符串JsonSerialize(using ToStringSerializer.class) private Long id;在Jackson的ObjectMapper里做全局配置也可以但直接在实体类字段上加注解更直观同事接手代码时能马上看出来。日期格式是另一处痛点。Java默认序列化的LocalDateTime输出是带T的ISO格式比如 2024-06-01T10:30:00前端拿到之后要么自己手动解析要么展示出一堆奇怪的字符。统一的做法是在后端配置统一的Jackson格式或者在每个日期字段加上 JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。前端再配一个dayjs做格式化全项目时间显示就保持一致了。4.3 图片上传的本地存储方案与静态映射房东发布房源时要上传封面和实拍图这是租房平台不可少的功能。我选择了最简单的本地存储方案图片上传到服务器的一个指定目录比如 /data/rent/upload/数据库里只存相对路径。这里有一个必须处理好的点用户通过浏览器访问图片实际上是向服务器的某个URL发起请求。后端需要把本地上传目录映射成一个HTTP访问路径。在SpringBoot里用WebMvcConfigurer就能实现Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/data/rent/upload/); } }配置完成后访问 http://域名/upload/xxx.jpg 时Nginx会直接去读取服务器磁盘上的文件。这样静态资源和动态接口完全分离数据库里也只存字符串路径查询压力小。图片上传的大小限制我也踩过坑。默认的Spring Boot上传限制是1MB手机拍的图一张动辄三兆如果不是用Element Plus自带压缩很容易出现上传失败这种毫无提示的错误。后来我在配置里把上传大小调整到10MB才彻底解决问题。生产环境还可以在前端先做压缩减少服务器存储压力。5. 从本地到线上完整部署流程的记录与验证5.1 环境准备与后端打包部署之前先把服务器的环境准备好。我用的是Linux系统需要安装JDK、MySQL、Nginx。JDK版本要和本地开发一致我用的Java 8部署时安装对应版本否则可能出现Class版本错误。后端打包前先检查配置文件。本地开发用application-dev.yml数据库地址是localhost。生产环境用application-prod.yml把数据库地址改成服务器内网地址账号密码单独设置。启动时通过启动参数指定使用哪个profilejava -jar rent-platform.jar --spring.profiles.activeprod打包命令很固定mvn clean package -DskipTests-DskipTests的意思是跳过测试用例。有些同学打包时没跳测试本地测试代码连不上开发数据库build直接失败。这一步可以省掉很多无谓的报错。打包完成后target目录下会生成一个可执行的Jar包。可以在本地先跑一下确认正常再上传服务器。5.2 前端构建与数据库初始化前端构建没有太多技巧关键是Node版本。前端项目我用的是Vite构建Vite对Node版本有要求版本太低会报错说不支持。建议用Node 16或者更高的版本。npm install npm run build构建完成后dist目录里就是静态文件。把这个目录整个传到服务器的某个路径比如 /data/rent/dist后面交给Nginx指向这个目录就行。数据库的部分我会把完整的建表语句和初始数据放到一个 db.sql 文件里。在服务器上初始化数据库有两种常用方式。一种是登录MySQL后执行 source 命令另一种是直接命令行导入mysql -uroot -p rent_db /data/rent/db.sql导入之前先在MySQL里创建好数据库否则会报数据库不存在的错误。导入完成后用几条简单的SQL验证一下表结构和数据条数做到这一步确认无误再继续往下走。5.3 Nginx反向代理与Vue history路由配置Nginx是整个部署链路里最关键的中间层。它能同时干两件事托管前端静态文件以及把接口请求反向代理到后端服务。我的nginx.conf配置思路如下server { listen 80; server_name your-domain.com; location / { root /data/rent/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /data/rent/upload/; } }有的同学会问try_files那行是干什么的这是专门给Vue Router的history模式准备的。页面在路由切换时路径是 /house/detail/123如果Nginx找不到对应的物理文件就会直接返回404。try_files会把这类的路径请求全部回退到index.html由前端路由去解析和渲染页面。没有这行配置刷新非首页路由就报404这是前后端分离项目部署时最高频的翻车点之一。location /api/ 里的代理也解释一下。前端Axios的baseURL统一配置成 /api所有请求都带着这个前缀发到Nginx。Nginx收到后把前缀对应的请求转发给后端端口同时保持Host等请求头不变。这样浏览器看到的请求地址始终是同一个域名不会产生跨域问题。5.4 启动服务与服务守护后端Jar包的启动方式基本是nohup配合日志输出nohup java -jar rent-platform.jar --spring.profiles.activeprod /data/rent/logs/app.log 21 nohup表示忽略挂断信号关闭终端后进程继续跑。日志输出到app.log文件排查问题直接看这个文件。不过nohup有个缺点服务器重启后Jar包不会自动启动。想省心建议配置systemd服务。创建一个服务描述文件把启动命令交给systemd托管设置开机自启这样比裸跑nohup稳定得多。服务起来后用下面的命令做一轮完整验证curl http://127.0.0.1:8080/api/user/login -X POST -d usernametestpassword123456有返回数据说明后端通。然后访问域名看前端页面登录、搜索房源、上传图片把核心链路走一遍。任何一个环节报错先看app.log再看Nginx的error.log。我用这条日志排查路径解决过绝大多数部署问题。6. 项目上线前后值得关注的六个优化与避坑点6.1 配置与依赖方面的常见坑第一件要提醒的是MyBatis的Mapper.xml文件没有被打进构建产物。Maven默认只把resources目录下的文件打包进Jar如果Mapper.xml放在src/main/java里面打包后就会发现启动时报错说找不到SQL语句。规范的做法是把Mapper.xml放到src/main/resources/mapper/目录下或者在pom.xml里显式配置资源目录。第二件是驼峰映射。MySQL字段习惯用下划线命名比如create_timeJava属性是createTime。MyBatis默认转换下划线为驼峰的功能没打开时查询结果里创建时间一直是null。在配置文件里加上mybatis: configuration: map-underscore-to-camel-case: true这个开关一行配置能救很多人半天的排查时间。第三件是分页。租房平台的房源列表必然要分页我用了PageHelper插件但它有个使用前提分页参数必须和查询语句在同一个线程里立即执行。如果中间隔了一次其他查询分页就会串到别的SQL上。小心使用PageHelper或者干脆自己用LIMIT加参数算偏移量也能稳定工作只是需要多写几条SQL控制权完全在自己手里。6.2 业务层面的细节优化房源列表的排序策略值得多说一句。最简单的方案是按发布时间倒序但这会导致房源信息一直变化用户每次刷新看到的位置都不一样。我加了一个权重机制把新发布的房源和时间做加权排序。具体做法是热点房源加权值高普通房源按创建时间加权整体的排序结果兼顾了新鲜度和稳定性。实现成本不高但带来的用户体验提升非常明显。租赁订单生成时一定要生成唯一的订单编号不要用自增主键直接当订单号展示给用户。订单号我一般这样拼当前时间戳加随机数加用户Id的末四位。这个编号作为平台和用户沟通的凭证也方便客服按号查单。6.3 安全与稳定性建议密码存储这块必须用哈希加密。BCrypt是Spring Security里自带的密码加密器即使两个用户密码相同加密后的结果也不同因为每次都会加入随机盐。接口层面登录接口要加简单的限流防刷机制。可以用拦截器按IP统计短时间内的请求次数超过阈值直接拒绝。网上教程里常见的那种不加任何防护的做法上线后很容易被脚本刷爆。MySQL的部署安全也很重要。生产环境不要用默认的3306端口不要给应用用root账号连接数据库单独建一个只拥有项目库权限的账号。这些操作在部署阶段多做一步后续就能少操心很多。最后说一点个人体会。租房平台看起来功能不算复杂但它把用户角色、状态流转、文件上传、高德地图标记、订单结算这些常见模块全都覆盖到了。把这样一个项目从设计到部署完整走一遍胜过看十遍教程。我给自己的要求是每一步报错都要弄明白原因再继续。按照前面这些思路做下来这个系统不仅能顺利跑通还能在性能和安全性上达到可上线标准。