又是一年答辩季。最近好几个人问我要同一个东西一个能做课程设计、又能当毕设的SpringBoot项目最好是市面上常见、老师认可、还带完整文档和源码的那种。我翻了下之前的工程目录正好有个存货——基于SpringBoot的大学生租房平台代码和文档都齐全当时花了三周做完最后拿了不错的成绩。这篇文章就把这个项目的设计思路、核心实现、踩过的坑全部分享出来给正在选题或者卡在开发中段的同学做个参考。这个项目本质上是一个典型的“信息发布订单流转”的Web应用业务核心围绕三条主线学生找房、房东管房、管理员维护平台运营。涉及的角色有三种用户流量入口和后台管理分开设计功能覆盖面足够撑起一篇像样的毕业设计论文代码量也能体现工作量。我当年选这个题的逻辑很简单租房是高频真实场景业务不复杂但足够完整从用户注册登录到房源发布、条件检索、在线下单、订单状态流转闭环感很强既不会做到一半发现没东西可写也不会简单到答辩老师看一眼就pass。下面我按项目的实际开发顺序来拆解从需求分析讲到数据库设计再到核心代码实现和踩坑记录最后聊聊文档编排和答辩演示的一些实操心得。1. 这个项目的需求分析与功能边界把“学生租房”这件事拆清楚1.1 学生租房和普通租房差在哪儿很多人看到一个租房平台第一反应是“这不就是58同城吗”。但既然是给大学生用的产品逻辑和普通租房平台有本质区别需求分析的时候就要把这些差异写进文档里这是论文第一章能有亮点的关键。学生的找房需求有几个典型特征一是价格敏感预算区间非常固定城市不同、校区不同价格带差异很大所以价格区间筛选是刚需不能只做一个模糊的排序二是时间周期短绝大多数学生的租期是半年到一年跟长租、整租的逻辑不一样所以房源信息里必须带“租期”字段三是信息真实性焦虑严重学生被假的“低价房源”骗过的案例太多所以平台设计里需要一个签约订单机制而不是像分类信息网站那样只做信息展示。基于这几个判断我把功能边界划定为学生端可以注册登录、浏览房源、多条件搜索、收藏房源、发起租房订单、查看合同信息房东端可以发布房源、上下架管理、处理收到的订单管理员端负责用户管理、房源审核、公告发布、订单监督。这样设计每种角色的核心诉求都得到了满足也保证了每个实体表都有业务动作支撑不会出现“建了一张表却没人用”的尴尬情况。1.2 功能模块划分让答辩老师一眼看懂系统全貌这个项目的功能模块图在论文里是重头戏我建议分成前台和后台两条线来画。前台面向学生和房东后台面向管理员。前台核心模块包括用户模块注册、登录、个人信息维护、密码修改房源模块房源列表展示、房源详情、多条件检索、收藏订单模块在线下单、取消订单、确认入住、到期退房、订单状态同步评论模块学生看房后对房源发评论、打分后台管理模块包括用户管理学生/房东账号的封禁与启用房源审核房东发布房源后管理员审核通过才可见订单监管查看全平台订单、处理异常状态公告管理发布系统公告前台首页展示数据统计房源数量、用户数量、订单数量的概览这块建议在项目文档里做成表格配合模块图一张图讲清系统边界答辩时开场的两分钟讲它就是最好的系统介绍。2. 技术选型与工程结构SpringBoot为核心的整体方案2.1 为什么是SpringBoot以及版本搭配逻辑这个项目我用了SpringBoot 2.5 MyBatis-Plus 3.5 MySQL 8.0的组合JDK用的1.8。理由很简单SpringBoot解决了Spring早期XML配置繁琐的问题内嵌Tomcat打成jar包就能跑对课程设计和毕设来说部署演示成本极低MyBatis-Plus 在MyBatis基础上提供了通用的Mapper CRUD和分页插件写查询不用手写大量重复SQL开发效率高不少MySQL 8.0是当下主流Navicat连上就能用团队合作其实很多是一个人也方便。有人问要不要上SpringCloud要不要用Redis我建议是不要。课程设计或本科毕设的评分标准是完整性、正确性、代码规范不追求高并发分布式你用Redis做缓存没问题但单机单体SpringBoot已经足够承载所有功能多引入中间件反而会增加答辩时被追问的风险。举个例子你用了Redis老师就会问“Redis的过期策略是什么”“缓存穿透怎么解决”答不上来反而扣分。2.2 项目工程的包结构与分层设计我当时的分层结构是这样的com.kaic.renting ├── controller // 接口层接收前端请求 ├── service // 业务层接口实现 ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── dto // 传输对象接收前端参数 ├── vo // 视图对象返回给前端的数据 ├── config // 配置类跨域、拦截器、MyBatis-Plus分页插件 ├── common // 公共结果封装、异常处理 └── utils // 工具类MD5、JWT等这套包结构看起来常规但很能体现分层思想。controller只做参数接收和结果返回业务逻辑全部下沉到service层mapper层只做数据访问。论文里的架构图、时序图都能从这套结构里直接画出来。分层有一个容易被忽视的好处是某些复杂查询可以在service层组合多个mapper的方法实现不必硬写在SQL里。比如房源详情页要展示房子基本信息和房东信息我就在service层先查house再查user拼装成一个详情VO返回给前端逻辑清楚代码也好看。3. 数据库设计五张核心表的关系与业务状态管理3.1 核心表结构与字段设计思路这个项目的数据库我总共设计了六张核心表用户表(user)、房源表(house)、订单表(order_info)、收藏表(favorite)、评论表(comment)、公告表(notice)。表名避免用order这种SQL关键字所以我用了order_info。用户表的关键字段除了常规username、password、phone、email之外还加了一个role字段用0表示学生、1表示房东。这里要强调一个细节我没有拆成学生表和房东表而是用一张表加角色字段区分。原因在于学生和房东在真实场景中身份是可以重叠的——一个学生毕业了也可以做二房东——用角色字段去控制权限比拆表更灵活查询也更方便。房源表是整个系统的核心字段设计如下字段名类型说明idbigint主键IDtitlevarchar房源标题imgvarchar房源图片URLcityvarchar城市addressvarchar详细地址pricedecimal(10,2)月租金areadecimal(10,2)面积house_typevarchar户型如一室一厅rent_typevarchar租期类型如整租/合租statustinyint0待审核 1已上架 2已下架 3已租出landlord_idbigint所属房东IDcreate_timedatetime创建时间这里特别注意price字段一定要用decimal不要用double或float。钱相关的字段用浮点类型会在精度上出问题例如计算租金总额时出现0.999999这种结果这在答辩演示时非常尴尬。我一开始图省事用了double后来在合同金额计算时发现了这个问题才改成decimal。这种细节写进论文反而能成为加分项。3.2 订单状态用整型枚举管理流转不用字符串订单表我设计的字段包括id、house_id、student_id、landlord_id、rent_time、rent_duration、total_price、status、create_time。其中status字段用整型表示0待确认学生发起待房东确认1已确认房东同意租约生效2已完成租期结束3已取消学生或房东主动取消为什么用整型不用字符串“待确认/已确认”因为整型在做条件查询和统计时效率更高也不容易出现中英文符号混用导致比对失败的问题。在代码里我会定义一个OrderStatus常量类把状态值和对应说明集中管理前端拿到数字后由前端做文本映射或者后端vo层转换成文本返回。这个做法在论文的“系统实现”章节里是一个很值得写一笔的设计决策。3.3 多条件检索场景下的索引与查询优化学生在首页搜索房源时最常用的筛选维度是“城市户型价格区间”。这种多条件组合查询在数据量不大时感觉不到差异但为了规范我在city、house_type、price字段上分别建了普通索引。MyBatis-Plus的QueryWrapper底层会自动拼接SQL索引能保证查询走索引而不是全表扫描。在订单表上我建了联合索引(house_id, student_id, status)因为业务中频繁出现的操作是查看某套房子的订单历史和某学生名下的订单列表。联合索引比单字段索引更高效这一点在项目文档的数据库设计部分一定要写清楚属于“设计亮点”。4. 核心代码实现登录鉴权、房源检索与订单状态的完整链路4.1 登录鉴权用拦截器统一校验登录状态学生和房东登录后都需要身份校验管理员后台也是独立入口。我用的是基于Token的简单鉴权方案不引入Spring Security因为如果引入Spring Security答辩时被问到的内容会非常多而且很多同学其实说不清楚其中过滤链的执行机制。具体实现用户登录成功后后端生成一个UUID作为token存到内存Map中简单场景够用同时把token返回给前端。前端把token存到localStorage每次请求在header中携带。后端写一个LoginInterceptor拦截器在preHandle方法中从header里取token如果不存在或无效就返回401错误码。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(token); if (token null || !TokenStore.isValid(token)) { response.setStatus(401); response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:401,\msg\:\未登录或登录已过期\}); return false; } User user TokenStore.getUser(token); request.setAttribute(loginUser, user); return true; } }拦截器注册到WebMvcConfig中并配置放行路径比如登录接口、注册接口、房源列表和详情接口都放行但收藏、下单、订单管理等接口必须登录才能访问。这里有一个关键是放行配置不能写错否则会出现“明明登录了却总是跳到登录页”的诡异问题我在下面会专门展开讲。4.2 房源多条件检索查询条件构造器的实践房源检索是前台的核心接口既要支持关键词模糊搜索也要支持城市、户型、价格区间、出租方式的精确筛选。用MyBatis-Plus的QueryWrapper来构造条件非常方便public PageHouse searchHouse(HouseQueryDTO dto) { PageHouse page new Page(dto.getPageNum(), dto.getPageSize()); QueryWrapperHouse wrapper new QueryWrapper(); wrapper.like(StringUtils.hasText(dto.getKeyword()), title, dto.getKeyword()) .eq(StringUtils.hasText(dto.getCity()), city, dto.getCity()) .eq(StringUtils.hasText(dto.getHouseType()), house_type, dto.getHouseType()) .ge(dto.getMinPrice() ! null, price, dto.getMinPrice()) .le(dto.getMaxPrice() ! null, price, dto.getMaxPrice()) .eq(StringUtils.hasText(dto.getRentType()), rent_type, dto.getRentType()) .eq(status, 1) .orderByDesc(create_time); return houseMapper.selectPage(page, wrapper); }这里有一个细节我当时差点忽略前端传递参数时如果某个筛选条件没选传过来的是空字符串而不是null如果直接调用wrapper.eq(字段, )SQL会变成where city导致一个本该筛选全部城市的请求变成了筛选城市为空的记录。MyBatis-Plus的eq方法第一个参数如果是false会自动忽略这个条件。所以我用StringUtils.hasText()来判断这一小段代码体现了对实际请求参数容错性的处理文档里可以大书特书。4.3 订单流程状态机思想在业务代码中的落地订单模块是这个系统里最有含金量的一块。学生发起订单后状态变化有严格的方向性待确认只能变成已确认或已取消已确认只能变成已完成已取消是终态。为了避免业务代码里出现“从已完成改回待确认”这种非法状态流转我封装了一个状态校验方法public boolean canChange(int currentStatus, int targetStatus) { switch (currentStatus) { case OrderStatus.PENDING: return targetStatus OrderStatus.RENTED || targetStatus OrderStatus.CANCELLED; case OrderStatus.RENTED: return targetStatus OrderStatus.COMPLETED; default: return false; } }在service层的confirmOrder、cancelOrder、completeOrder三个方法里都先调用canChange校验不通过就抛出业务异常。这种写法不是教科书的生搬硬套而是真的在防止脏数据的产生。我在写论文“系统详细设计”章节时把这个状态机画成了一张状态流转图配上这个校验逻辑答辩老师看完连连点头说这比很多学生的“订单状态随便改”要成熟。订单创建时还会涉及几个联动操作同一套房源如果已经存在待确认或已确认的订单就提示“该房源已被预订”同时把房源状态改为3已租出避免重复租给两个人。这个业务规则是租房平台真实性的关键也是答辩时可以展示的亮点讲清楚如何用一条查询语句和一个状态更新保证房源与订单的一致性。5. 实盘踩坑记录跑通代码比写代码更费时间的三个典型问题5.1 跨域配置与拦截器放行的顺序冲突我第一次联调的时候前端页面访问后端接口一直报跨域错误。查了半天发现跨域配置本身没问题但问题是拦截器执行顺序在跨域处理之前——预检请求(OPTIONS)直接被我写的LoginInterceptor拦住了连跨域过滤器都没机会执行。解决办法是在拦截器的preHandle里直接放行OPTIONS请求if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; }同时WebMvcConfig里实现CorsRegistry配置允许所有来源、所有方法、所有header。这个小问题折腾了我一个下午。写代码最怕这种“配置写好了但没生效”的情况建议同学们联调时打开浏览器开发者工具先看network面板看是不是OPTIONS请求返回了401。定位到这个问题后续就顺利了。5.2 MyBatis-Plus分页插件不生效的坑按照MyBatis-Plus官方文档使用分页功能需要配置分页插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类如果漏了selectPage方法只会返回全量数据然后用内存分页的方式伪装成分页结果。接口看起来是正常返回了但实际执行的SQL里根本没有LIMIT。数据量小的时候感觉不出来一旦数据量大就会OOM。踩坑的根源是我第一次项目里忘了加Configuration注解导致分页拦截器根本没被Spring容器托管。排查方法很直接打开MyBatis-Plus日志看输出的SQL里有没有LIMIT语句。这种问题在论文和技术总结里非常值得写因为几乎所有用MyBatis-Plus的人都会遇到。5.3 日期格式化导致的时间差问题房源列表页展示发布日期时需求是显示“2024-05-20”这种格式但接口返回的是“2024-05-20T14:30:00”这种ISO格式。前端直接渲染会出现一个T字母观感很差。这个问题本质是SpringBoot默认的Jackson序列化配置导致的。解决办法有两个一是在实体类的日期字段上加JsonFormat注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime createTime;另一个是全局配置统一序列化格式。我最后用了全局配置因为实体类很多一个个加注解太啰嗦而且全局配置能保证所有日期字段格式一致。还有一个容易忽略的点MySQL驱动连接串里要加serverTimezoneAsia/Shanghai否则从数据库读出时间再序列化可能出现整整差8小时的情况。6. 论文文档的编排思路与答辩演示的高分技巧6.1 文档结构怎么写才不会被老师挑刺这份项目的文档如果按标准的毕设论文目录来组织大概分六章绪论、相关技术介绍、系统分析、系统设计、系统实现、系统测试。很多人的相关技术介绍部分写出来就是官网文档的搬运工什么“SpringBoot是一个用来简化Spring应用的初始化搭建及开发过程的框架”这种话没有任何信息量。我的建议是每一段技术介绍后面都要跟一段“为什么本项目选择该技术”。比如MyBatis-Plus那一段写完官方定义后加一句“本系统中的多条件房源检索功能借助QueryWrapper动态拼接查询条件相比传统XML配置SQL的逐条拼接方式代码量减少约四成”。这样写老师一看就知道你是真用过了而不是在抄资料。系统分析章节需要有可行性分析和需求分析。需求分析要画用例图把三种角色的用例都列出来。系统设计章节包含架构设计、功能设计、数据库设计、核心流程设计。这里的时序图不是必备但如果你画了学生下单的时序图会显得非常专业。实现章节配核心代码测试章节写功能测试用例表每个用例包括操作步骤、预期结果、实际结果。6.2 答辩现场的三点实操建议答辩想拿高分光有项目还不够演示手法也很重要。我总结三点第一准备一份演示数据。不要现场注册账号不要现发房源把几个不同城市、不同价格段的假数据提前插库保证演示时搜索结果的丰富度。现场现注册现发帖容易出操作失误而且显得准备不充分。第二把“核心亮点”设计成一条演示链路。我的链路是注册一个房东账号 - 发布房源 - 管理员审核通过 - 切换学生账号 - 搜索到房源 - 下单 - 房东确认 - 订单状态流转。一条链路把所有角色的核心功能串起来评委看完对整个系统就有了完整认知比零散地这里点点那里看看效果好十倍。第三准备几个“被追问”的防御性答案。比如老师问“并发情况下同一套房会不会被同时下单”时我直接讲了订单创建前的状态校验和数据库状态更新保证逻辑这就是4.3节那段代码的价值。这类具有防御性质的技术细节是你区别于其他同学的硬实力。我在完成这个项目后有一个很深的体会课程设计和毕设项目并不需要你造出什么惊天动地的应用它考察的是你对一套完整业务需求的理解能力和工程化实现能力。租房平台的每一种角色、每一个字段、每一次状态变化都对应真实的业务逻辑。把这份逻辑讲清楚、写成文档、代码干净规范就已经是一份很稳的交付了。如果你也在做类似的项目建议别急着写代码。先把需求拆透、表结构设计好、状态流转图画出来代码实现只是最后的落地工作。项目做完后把这个过程整理成文档你会发现四年的知识在这个项目里真正串了起来。