每年到这个时间总有人问“Java毕业设计做什么题目比较好”。我的回答往往是从一堆推荐里把“在线租房系统”拎出来单独说。这个题目不是最惊艳的但它有一种难得的平衡业务上能讲清楚技术上能踩到后端开发的核心点又能扩展出爬虫、数据可视化、小程序甚至分布式这些加分项。自己把完整项目做下来之后会发现它能撑起的不只是一份代码而是一整套从需求、设计、编码、测试到论文答辩的完整毕业设计流程。这篇文章就结合我自己的项目经验把选题逻辑、系统设计、核心实现、数据采集可视化、论文答辩全部拆开讲一遍希望给正在犹豫选题或者已经选了这个题目的朋友一些可落地的参考。1. 为什么选“在线租房系统”作为毕业设计题目1.1 业务复杂度恰到好处能写进论文的东西足够多毕业设计最怕两种一种是“学生信息管理系统”这类纯增删改查代码写完了论文没话讲另一种是“大型电商平台”这类需求、部署、功能都压死人学生在两个月内根本做不完最后只能拿半成品去答辩。租房系统正处在两者之间的舒适区。从用户侧看它有租客和房东两个完全不同的角色权限和操作逻辑都不一样从业务流程看它覆盖了房源发布→搜索→详情→收藏→预约/下单→订单管理这条完整链路每一环都可以单独展开讲。加上图片上传、多条件检索、评论统计这些点论文的需求分析、系统设计、模块实现、系统测试四章都有充足素材不用硬凑字数。另外这个题目还有一个很实际的优点数据好找。房源信息是公开的价格、区域、户型这些字段到处都有可以用爬虫抓一批真实数据到本地库系统一打开就有几百条数据演示效果完全不一样。这也解释了为什么现在很多毕业设计项目都会把“爬虫数据可视化”绑在一起因为这两个模块能让系统从“看着简陋”直接提升到“有点东西”的级别。1.2 从需求清单到页面清单先画清楚再做动手写代码之前我强烈建议先做一次需求整理不要上来就建Spring Boot项目。我给自己定的功能清单是这样的前台用户端注册登录、房源检索关键词/区域/户型/价格区间、房源详情、图片浏览、收藏/取消收藏、评论打分、预约看房、提交租房订单、个人中心我的订单/我的收藏/我的房源后台管理端管理员登录、用户管理禁用/启用、房源审核通过/驳回、房源上下架、订单处理、数据统计面板页面层面大概就是这些首页、房源列表页、房源详情页、登录/注册页、个人中心页、管理后台的六个子页面。把这些页面名和功能对应上后面开发就不会东一榔头西一棒子。实际有经验的开发会说可以把前台和后台拆成两个独立的前端工程。我当时就是这么做的好处是权限逻辑清晰管理端单独部署坏处是多一套代码量。如果时间紧也可以把管理员模块直接集成在同一套前端里用路由守卫控制访问代码量会少很多但演示的时候要提前切好账号。1.3 项目编号与“完整源码”这件事我在整理这套项目的时候习惯给每个版本打编号比如标题里的0215代表某一轮的完整交付版本。很多同学买源码或者找学长要源码第一句话就是“有没有完整源码”但源码拿到手之后怎么跑起来、怎么改、怎么在答辩里讲清楚才是真正的问题。所以我整篇文章不只是讲“有哪些功能”而是把每个模块的设计思路和实现细节都说明白这样你拿到任何一套代码都能自己捋清楚。2. 从零搭建系统技术选型与数据库设计2.1 后端为什么是Spring Boot MyBatis-Plus而不是SSH早几年的教材还停留在SSHStruts2SpringHibernate现在再拿这套框架做毕业设计代码量巨大配置还麻烦。Spring Boot把它简化到几乎是“开箱即用”非常适合毕业设计周期。Maven一拉依赖一个main方法启动内嵌Tomcat不用单独装服务器这对学生党来说太友好了。MyBatis-Plus说白了就是MyBatis的增强版单表CRUD不用写SQLBaseMapper直接继承分页也有现成插件。这在写房源、订单、收藏这些基础模块时能省下大量时间而且论文里写“使用MyBatis-Plus提高开发效率”也是一个站得住的理由。至于为什么不直接上MyBatis不是不行只是没有Plus省事毕业设计时间本来就紧能少写重复代码就少写。如果项目里要强调安全可以再加Spring Security或Sa-Token。我个人建议不要为了堆技术乱加框架Spring Boot MyBatis-Plus MySQL Redis Vue Element UI ECharts这一套组合对毕业设计来说已经足够饱满。Redis不是必须的但加了之后可以处理验证码缓存、热点房源缓存、分布式锁这些点论文里又能多写两页。2.2 核心表结构设计八张表就能闭环不把表设计好后面就是无尽的返工。我设计的核心表如下你可以直接参考表名作用关键字段t_user用户表id, username, password, role, phone, avatar, status, create_timet_house房源表id, landlord_id, title, description, price, area, address, district, house_type, orientation, status, cover, create_timet_house_image房源图片表id, house_id, image_url, sortt_order订单表id, order_no, user_id, house_id, status, start_date, end_date, amount, create_timet_favorite收藏表id, user_id, house_id, create_timet_comment评论表id, house_id, user_id, content, rating, create_timet_district区域表id, name, code, parent_idt_admin管理员表id, username, password, last_login_time用户表里我用role字段区分租客/房东没有做成单独的两张表因为这两个角色的基础信息是一样的只是业务权限不同。房东在“我的房源”里维护自己发布的房子租客在订单模块里下单通过user_id和landlord_id两个外键关系就能串起来。房源表注意几点status字段控制房源状态1在租、0下架、2待审核这个字段贯穿前后端price用DECIMAL(10,2)存别用字符串不然后面做排序和统计的时候全是坑cover字段存封面图URL减少一次联查。订单表里order_no用时间戳随机数生成保证唯一性因为订单号在演示时经常会被截图看起来要正式一点。2.3 文件上传与图片访问路径房源多图上传是躲不开的节点。我当时把图片保存到本地磁盘的D:/upload/目录Spring Boot里配置了一个映射把 /upload/** 映射到物理路径前端直接拼URL就能访问。为了论文里好看我在代码里把上传逻辑写成了独立的上传工具类支持图片格式校验和大小限制比如单张不超过2MB。生产环境一般用MinIO或者OSS但在毕业设计里本地磁盘存储完全够用部署时多带一个说明就行。这里特别提醒一句如果你直接把图片存到数据库的BLOB字段里开发时会很酸爽数据库文件迅速膨胀备份也慢。用路径存URL图片文件放磁盘是更常规的做法。3. 四个必须写清楚的核心业务模块3.1 登录注册与JWT鉴权这个模块几乎是所有系统的门面也是答辩时老师必问的地方。我最后用的是JWTJSON Web Token方案用户登录成功后后端生成一个token返回前端前端每次请求在Header里带上Authorization: token后端通过拦截器解析token确认用户身份。核心逻辑其实就三段登录接口根据用户名查用户用BCrypt校验密码成功后生成token拦截器从Header中拿token并解析出userId需要权限的接口比如管理员接口再额外校验role字段。用BCrypt而不是MD5的原因很简单MD5加盐也很容易被彩虹表破解BCrypt是自适应哈希计算慢反而更适合密码存储。这里给出一个简化的登录接口片段PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userService.findByUsername(dto.getUsername()); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.success(new LoginVO(token, user.getRole())); }代码不用多复杂但逻辑要完整得能回答“session和token的区别”“JWT过期时间怎么设置”这类追问。我当时把token过期时间设成了2小时前端在axios的响应拦截器里统一处理401状态码跳回登录页这样比每个页面自己判断要省事得多。3.2 房源发布与多条件检索房源发布是房东端的主要功能表单字段比较多标题、描述、租金、面积、区域、地址、户型、朝向、图片。提交时把基本信息插入t_house再把图片批量插入t_house_image用事务保证一致性。这里最容易翻车的点是图片上传和房源保存不是同一个接口我踩过一次坑后来改成先上传图片返回URL列表再和房源基本信息一起提交。所以接口设计上上传接口和发布接口是分开的前端先调上传再调发布。检索是房源列表页的核心。前端把筛选条件传过来后端做成动态SQL关键点是用好MyBatis-Plus的QueryWrapper或者XML里的动态标签防止拼接SQL出错。大致的查询条件组合是这样的SELECT * FROM t_house WHERE status 1 AND (title LIKE CONCAT(%, #{keyword}, %) OR address LIKE CONCAT(%, #{keyword}, %)) AND district #{district} AND price BETWEEN #{minPrice} AND #{maxPrice} AND house_type #{houseType} ORDER BY create_time DESC LIMIT #{offset}, #{pageSize}条件为空时就不加对应字段MyBatis的 标签刚好干这个。分页参数用PageHelper或MyBatis-Plus的分页插件都能搞定写好之后最好用不同条件组合测一遍尤其是“什么都不选”的时候不能报错要返回全部在租房源。还有一个小细节关键词搜索建议同时匹配标题和地址这样用户搜“滨江”或者搜“两室一厅”都能命中。3.3 订单提交与状态管理订单模块是业务流程里最容易出逻辑问题的部分。我的设计是一个状态机流转待支付 - 已支付待入住 - 已入住 - 已完成 待支付 - 已取消租客提交订单时后端至少要做三重校验房源必须存在且状态为在租同一房源当前时间段不能已有冲突订单当前用户不能重复提交同一个房源的订单。第一重校验是常规操作第二重用一条SQL查订单表就能解决SELECT COUNT(*) FROM t_order WHERE house_id #{houseId} AND status IN (1, 2, 3) AND start_date #{endDate} AND end_date #{startDate}这条SQL的意思是只要别人订单的有效时间区间和本次提交的重叠就说明有冲突。这是我当时改了三版才踩明白的写法一开始用单个日期判断结果跨天订单总是冲突。比如有人订了3号到5号又有另一个人想订4号到6号单看某一天判断发现不了必须用时间区间交叉判断。支付这块说实话在毕业设计里做真实支付对接没必要容易卡在商户号申请。我采用的是“模拟支付”前端弹窗选择支付方式后端直接把订单状态从未支付改成已支付同时记录支付时间。只要在论文里说明“由于毕业设计环境限制支付功能采用模拟方式实现”老师一般不会为难。如果你想把这一步做得更完整可以引入支付宝沙箱环境但流程复杂不少非必要不建议。3.4 后台管理的权限控制与数据面板后台管理端不一定要登录后所有接口都能调我自己加了一个简单的角色判断拦截器只有role1的管理员才能访问/admin/**下的接口。前端也做了路由守卫用户看不到管理后台的菜单但真正的安全防线还是在后端接口层前端隐藏只是体验问题。管理端的房源审核逻辑是这样的房东发布房源后status2待审核管理员在后台看到待审核列表点击通过就把status改为1点击驳回就改成3并填写原因。这样做的原因是可以让论文里多一个“业务流程闭环”的亮点而不是简单的CRUD。审核驳回后房东在前台个人中心能看到驳回原因修改后重新提交这就是一个完整的状态流转。数据面板其实是决定项目“看起来高级不高级”的关键。我统计了三个必展示的指标出租房源总量、今日新增订单数、平台注册用户数再加两个可视化图表各区域房源数量柱状图、近7天新增订单折线图。这些数据都来自SQL的聚合查询比如SELECT district, COUNT(*) FROM t_house WHERE status 1 GROUP BY district后台返回Map或List前端用ECharts渲染一张图往往比一段文字说明更能让答辩老师眼前一亮。我记得答辩的时候老师在我数据面板那一页停留的时间明显比别的页面长还追问了“这个柱状图的统计口径是什么”所以自己一定要清楚数据怎么来的。4. 爬虫采集房源数据与可视化大屏的实现思路4.1 为什么需要爬虫以及怎样保证合规很多同学做这个系统时根本没有真实房源数据只能手动造十几条假数据演示起来很干。我当时用Python写了一个数据采集脚本从公开的租房信息平台把海报级的公开字段抓下来比如标题、租金、户型、面积、所在区域存到数据库里系统一打开就有几百条真实感很强的数据。这里必须强调一个原则爬虫是用来采集公开的、零散的、非隐私的数据并且只用于个人学习和毕业设计演示不对数据进行二次售卖或商业使用同时控制请求频率遵守目标网站的robots协议不抓取用户个人隐私信息比如联系电话、住址等。把这一条写进论文的“技术规范”部分反而会成为加分项因为老师能看出你有合规意识。4.2 采集脚本的落地写法我的脚本技术栈是Python requests BeautifulSoup pymysql。requests负责发请求BeautifulSoup负责解析HTMLpymysql负责写入MySQL。流程三步请求列表页、解析房源字段、批量入库。简化后的核心代码差不多是import requests from bs4 import BeautifulSoup import pymysql headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def parse_house(html): soup BeautifulSoup(html, html.parser) items soup.select(.house-list .house-item) result [] for item in items: title item.select_one(.title).get_text(stripTrue) price item.select_one(.price).get_text(stripTrue) district item.select_one(.district).get_text(stripTrue) house_type item.select_one(.type).get_text(stripTrue) result.append((title, price, district, house_type)) return result def save_to_db(data): conn pymysql.connect(hostlocalhost, userroot, password123456, databaserent_house_db, charsetutf8mb4) cursor conn.cursor() sql INSERT INTO t_house (title, price, district, house_type, status) VALUES (%s, %s, %s, %s, 1) cursor.executemany(sql, data) conn.commit() cursor.close() conn.close() if __name__ __main__: resp requests.get(https://example.com/zufang, headersheaders, timeout10) houses parse_house(resp.text) save_to_db(houses) print(f共入库 {len(houses)} 条数据)写在论文里的时候不需要长篇幅贴代码重点是讲清楚三部分抓什么、怎么解析、怎么入库。实际部署时建议加一个sleep防止请求过快也可以用random随机UA让自己更像一个正常用户避免给目标网站服务器带来压力。4.3 数据清洗从“3000元/月”到能统计的数值型字段爬下来的数据不是拿来就能用尤其是价格和面积经常是“3000元/月”“80平米”这种带单位的文本。直接存进数据库也能显示但做聚合统计和可视化时就废了。我写了一个清洗函数把价格字符串里的数字提取出来统一转成整数面积同理。区域字段要做映射保证同一个区域在数据库里只有一个叫法否则“滨江”和“滨江区”会统计成两个区。这一步我是用Pandas处理的读出来、正则替换、去重、再写回数据库。关键是清洗逻辑要和爬虫脚本分开单独写成一个Python文件这样以后换数据源或者增加其他字段都不需要动爬虫主流程。比如价格字段我用的正则很简单re.search(r\d, price_str)然后转int面积同理。遇到“整租·滨江”这种复合字段我再用split拆开后面那块作为户型存。4.4 可视化面板的前后端配合数据可视化不能只做一张图我做了三个核心图表区域房源分布柱状图、热门区域平均租金排行、户型占比饼图。后端统一返回JSON结构{ districts: [滨江, 西湖, 余杭], houseCounts: [120, 85, 96], avgPrices: [4500, 4200, 3800] }前端用一个统计接口获取全部数据采用组件化方式每种图表一个Vue组件数据通过props传入ECharts的初始化放在mounted里这样页面代码不臃肿。如果你没做过ECharts记住一个大原则ECharts的配置项核心就是series数组和xAxis/yAxis数据格式准备好剩下的都是抄配置和改样式。示例myChart.setOption({ tooltip: { trigger: axis }, xAxis: { data: this.districts }, yAxis: {}, series: [{ type: bar, data: this.houseCounts, barWidth: 30 }] });这套图表逻辑不只用在管理后台我还在首页做了一个简版的“租房热点板块”用户进入首页就能看到城市各区域的平均租金排行榜体验和数据感都拉满。视觉上不需要多惊艳配色统一、数据准确、图表类型贴合业务就已经能打动人了。5. 毕业设计全套文案准备与答辩避坑指南5.1 文案不是凑字数而是把你的实现讲清楚标题里提到了“全套文案”其实说的就是毕业设计配套的文档包我以前整理过一套包含开题报告、任务书、中期检查表、毕业论文、答辩PPT、演示视频脚本、系统部署README。这些东西单独看都不难难在互相配套比如论文里的截图要和你实际系统的界面一致PPT里的架构图要和论文里的架构图一致不然答辩时一被追问就露馅。论文提纲我建议按这个顺序来摘要和关键词绪论研究背景与意义、国内外现状需求分析可行性分析、功能需求、非功能需求系统设计总体架构、功能模块设计、数据库设计系统实现核心模块的截图和关键代码说明系统测试测试用例、测试结果总结与展望。最容易出彩也最容易翻车的是数据库设计部分只贴建表语句不行一定要配合ER图和字段说明。表与表之间的关系比如用户和房源的一对多、房源和订单的一对多要在文字里讲透。开题报告的核心是“你打算做什么、为什么做、怎么做、预期成果是什么”这四段写清楚就够了。任务书一般会由学校给模板你填的是研究内容和进度安排。演示视频脚本这份材料经常被忽略其实很有用提前写好“打开系统→登录→浏览房源→下单→后台审核→查看数据面板”的流程录制的时候就不会卡壳。5.2 答辩高频问题提前把答案背熟根据我自己的答辩经历老师几乎不会逐行审查代码他们更看重你是否真正理解系统。高频问题就这么几个我整理了下系统用了哪些表表之间什么关系——答八张核心表用户表、房源表、订单表、收藏表、评论表……关系用外键串联用户可以发布多个房源房源对应多个订单。为什么选Spring Boot和MyBatis-Plus——答Spring Boot简化配置、生态成熟MyBatis-Plus减少单表CRUD的重复代码开发效率高。登录是怎么保持会话的——答使用JWT登录后生成token前端存储在本地请求头携带后端拦截器校验。订单并发重复提交怎么处理——答数据库唯一索引加业务逻辑校验同一房源同一时间段只能有一条有效订单需要时使用Redis分布式锁。爬虫数据来源合法吗——答只采集公开字段遵守robots协议控制访问频率仅用于学习演示不涉及个人隐私和商业使用。系统部署在哪里——答本地部署后端打包成jar包运行前端npm build后由Nginx或Tomcat托管提供部署文档。每个问题回答3-5句话就行但一定要用自己的话不要背网上的范文老师一追问细节就尴尬了。我见过太多同学“为什么用MyBatis-Plus”这个问题背得滚瓜烂熟结果老师一句“那你给我说说BaseMapper里常用的方法有哪些”就愣住了所以基础API的用法还是要自己动手写过才有底。5.3 我在实操中踩过的坑希望你别再踩第一坑是图片路径。开发时我用的是绝对路径D:/upload结果换电脑演示时路径不存在图片全部404。后来我改成读取配置文件里的上传路径前端显示时用相对路径 /upload/xxx.jpg加上Spring Boot的静态资源映射换机器只需要改配置文件。这个坑很容易忽略但演示效果影响特别大。第二坑是数据库时区。MySQL连接字符串里如果不加serverTimezoneAsia/Shanghai本地可能没问题部署到服务器后时间会差8小时订单时间显示全错了。这个问题排查了我一个下午最后发现是时区配置问题连接串里加参数就解决了。第三坑是Demo环境里的网络。答辩教室的WiFi经常不稳定如果你把ECharts的JS文件从CDN引入断网后图表全部白屏。我最后把所有静态资源都下载到本地答辩时拔网线也能正常演示。这个细节看着小但真正关键时刻能救你一次。还有一个小技巧答辩演示前提前把系统数据准备好比如登录几个测试账号、预置房源和订单数据不要把当场注册、当场发房源的流程放在演示里线上环境一旦网络波动或者验证码接口出现问题节奏就全乱了。我当时把三个账号的登录信息打印在一张纸上租客、房东、管理员各一个演示的时候切账号非常顺滑。最后想说项目编号0215这个版本我整理过整套源码、文档和演示资源但其实比这些更重要的是你真的把系统的每个模块跑明白。别人给不了你对系统的理解只有你自己把代码一行行写下来、把数据一次次调通到了答辩现场才有底气。这套Java在线租房系统做完之后你还可以把它改造成车位出租、会议室预约、宠物寄养之类的系统换汤不换药核心模块也就是这些。如果你打算换一套技术路线比如前端改成小程序、后端改成Python或者其他语言这套表结构和业务流程同样可以直接平移过去关键是把这条业务闭环吃透。