简介一份基于Java的房屋租赁系统设计与实现文档适合计算机相关专业学生、开发者及需要搭建租赁平台的项目人员参考。文档以毕业设计/课程设计形式呈现系统阐述研究背景与现状并覆盖Java、MySQL、B/S结构、JSP等技术选型从可行性分析到项目设计目标与原则再到系统流程、架构设计、数据库实体与表设计内容层层递进管理员登录、管理员功能模块、前台首页及用户功能模块的实现与测试环节均有说明可直接作为同类系统开发的蓝图和毕业论文的写作范本。压缩包内为单个docx文件大小3.86MB目录结构完整含摘要、目录、各章正文、参考文献等已有51人学习对理解房屋租赁系统全生命周期和Java Web项目开发很有帮助。1. 房屋租赁系统JSP 毕设项目的完整拆解与落地近两年找我咨询毕设的人里做「房屋租赁系统」的比例一直不低但大多数人的第一反应是这题是不是太老了JSP MySQL MyEclipse这套组合在 Spring Boot 满天飞的当下还有没有复现价值我可以直接说结论这个题目恰恰是 Java Web 课程设计里最经典的一条线角色模型清晰管理员、用户、前台首页业务闭环完整房源发布、租赁下单、合同管理数据库表关系不复杂但足够支撑基本功展示。它不像电商系统那样堆模块也不像图书管理那样单薄拿来练手、应付答辩、甚至是作为转 Spring Boot 前的过渡项目都合适。我拆分这份资源时核心关注点不是「它有多先进」而是「照着做能不能跑通、改起来是不是顺手」。这篇笔记就把我拆到的技术细节、完整跑通的步骤、以及最容易把新人卡住的坑一次说清楚。2. 从需求到模块三个角色与业务边界2.1 管理员端的六块核心管理职能这个系统的权限设计走的是最典型的「单管理员 多用户」模式。管理员端一共六个功能域个人中心、用户管理、公告信息管理、房屋类型管理、房屋信息管理、租赁订单管理、合同信息管理外加一个系统管理。这里面容易理解出偏差的是「系统管理」——它在这个项目里不是指操作系统的配置管理而是指管理员对自己的登录密码、个人资料这类信息的维护。也就是说管理员不只是房子的发布者还承担了整个平台的基础数据维护职责。从实际拆解来看管理员与用户、房屋、订单、合同这四类核心数据之间是「一对多」的关系。一个管理员可以发布多条公告、维护多个房源一个用户可以产生多条租赁订单一个订单最终会对应一份合同。这种关系在数据库层面直接反映为主键外键的级联比如用户表被删除时他名下的订单和合同是保留还是清空取决于你写外键时用的是级联删除还是逻辑删除。这个项目用的是逻辑删除思路——数据记录还在只是sfsh这类审核状态字段把未通过的订单或房源「藏起来」。管理员的功能实现里最值得关注的是审核流。用户在前台提交租赁订单后订单并不会立刻生效而是要经过管理员在后台确认。这个确认动作落到代码上其实就是更新订单表里的审核状态字段然后同步更新合同信息表是否生成记录。我拆到的实现里订单表zulindingdan里专门有两个字段sfsh是否审核和shhf审核回复这就是审核功能的落点。很多初写者容易忽略这个字段设计导致功能上根本没有「待审核」这个中间态。2.2 用户端从浏览到收藏的完整链路用户端的模块看起来比管理员少——个人中心、租赁订单管理、合同信息管理、我的收藏管理——但用户在前台首页能做的操作远不止这些。用户可以在首页浏览公告和房屋信息查看房源详情提交租赁意向把心仪的房源收藏到个人中心。也就是说前台首页是「面向浏览」的用户中心是「面向管理」的两者通过用户登录态串联。这个「双中心」设计对动手改项目的人来说是个提示如果你想在答辩时加分可以在前台首页的房源列表上加一个「只看可租」的筛选条件后台对应就是zhuangtai字段的过滤。这个字段在房源表里默认是字符串类型取值一般是「已出租」「未出租」这类中文字面值不是布尔值。改的时候要注意——如果你把它改成0/1的 int 类型那所有涉及查询的地方都要同步调整这个细节特别容易漏。用户端还有一个很容易被忽视的功能我的收藏管理。收藏的本质是把房源 ID 和用户 ID 关联起来但没有单独建一张收藏表——它挂在用户表下面。这在数据量小的时候没问题但如果想做扩展建议单独拆一张shoucang表字段就三列id、user_id、fangwu_id。为什么建议拆因为收藏本身是一个「多对多」关系用户和房源之间是多对多的不拆表的话一旦用户删了或者房源下架收藏记录的清理逻辑就很别扭。2.3 权限边界的判断标准这套系统里判断权限的规则其实非常简单能进后台的就是管理员能操作自己数据的只有用户本人。管理员能看所有用户的订单和合同但用户只能看自己的。这个边界在 JSP 页面里是通过在每页顶部做 session 判断来实现的比如后台管理页面会校验session.getAttribute(cx)是否为管理员角色。拆这个项目时我注意到一个经验不足的人常犯的错误很多人在写「删除用户」功能时直接把用户相关的订单、合同、收藏全部物理删除结果数据库外键约束直接被触发报错。正确的做法是先把关联表的数据处理掉再删主表记录或者在表设计阶段就把外键的ON DELETE行为定义为SET NULL或CASCADE并清楚自己在做什么。我在下面第四章会给出表结构时专门标注这一点。3. 技术选型与运行环境JSP、MySQL、B/S 的组合逻辑3.1 为什么这个阶段选 JSP Servlet 而不是 Spring Boot很多人拿到这个资源时会有一个困惑既然是 2024、2025 年的节点了为什么还在用 JSP这里要分两层说。第一层是资源本身的定位它就是一份课程设计/毕设资源要求的技术栈是学校教学体系里的经典组合——JSP 用于动态页面渲染Servlet 处理请求分发JavaBean 封装业务逻辑MySQL 做持久化存储。这套组合虽然老但是它能完整展示 JSP 的生命周期、请求-响应模型、session 管理等 Java Web 基础概念而这些概念恰恰是 Spring Boot 里被隐藏掉的底层细节。第二层是从「改造」角度看。如果你想在这个项目基础上升级成 Spring Boot MyBatis 的版本JSP 这套思路反而是个非常好的参考底座。因为它的业务逻辑、SQL 语句、数据表设计都是可以平移的你只需要把页面渲染层从 JSP 换成 Thymeleaf 或 Vue 的前后端分离把 DAO 层换成 MyBatis 的 Mapper业务逻辑搬进 Service 层即可。我拆这份资源时有一个推荐路径先照着 JSP 版本把功能跑通、看明白数据怎么流转再试着用 Spring Boot 重写一次完成两件事。另外要提一下 MyEclipse 这个开发工具。它是 Eclipse 的 Java EE 增强版自带 JSP 编辑器、Tomcat 集成、MySQL 插件可以说是当年做 JSP 项目的标配。现在你用 IDEA 社区版或者最新版 Eclipse 也是完全可以的只是需要手动配置 Tomcat 和数据库连接没有 MyEclipse 那么「开箱即用」。这个资源里给的代码不需要绑定 MyEclipse它只是个开发环境不是运行依赖。3.2 B/S 架构下请求是怎么走完一圈的B/S 结构Browser/Server在这个项目里的表现就是浏览器负责发请求和渲染页面服务器端的 Tomcat 负责接收请求、调用 JSP/Servlet、访问 MySQL 数据库、把处理结果以 HTML 形式返回给浏览器。在这个结构下客户端几乎不做业务逻辑所有关键数据都在服务器端处理。好处是部署简单用户不用装任何客户端浏览器输入地址就能访问坏处是服务端压力大而且页面刷新是整页刷新交互体验不如现代的 AJAX 方案。拆代码的时候看 JSP 页面的请求流转是理解整个项目最快的办法。拿登录举例用户在login.jsp输入用户名密码表单提交到loginServlet或对应的 actionServlet 里通过 JDBC 查询allusers表验证账号验证通过后把用户信息放到session里然后response.sendRedirect()到首页或后台。这个流程里最核心的是 session 的存活时间——Tomcat 默认 session 超时是 30 分钟如果用户在后台操作到一半超过 30 分钟没动session 失效下一个请求就会跳回登录页。这在做功能演示时很容易被当成 bug实际上不是它只是 session 机制在正常工作。3.3 环境安装的版本配对建议JSP MySQL 这套技术栈虽然老但版本配对还是有讲究的。根据我拆这份资源的经验给你一组少踩坑的组合组件推荐版本说明JDK1.88u202 及之后太新的 JDK 在旧版 MyEclipse 里可能跑不起来Tomcat8.5.xTomcat 9 开始移除了部分旧 JSP 库兼容性不如 8.5MySQL5.7.x8.0 也可以用但 JDBC 驱动要注意换mysql-connector-java-8.0.xMyEclipse2019 或更早版本新版 MyEclipse 对新系统支持更好但配置逻辑相似为什么特意提醒 MySQL 版本因为这个项目里的建表语句用的是标准的varchar和int类型没用到 MySQL 8.0 的新特性所以 5.7 和 8.0 在表结构层面没区别。但 8.0 的 JDBC 驱动类名从com.mysql.jdbc.Driver换成了com.mysql.cj.jdbc.Driver而且连接 URL 还需要加上useSSLfalseserverTimezoneUTC之类的参数否则会报时区错误。这是初跑这个项目最容易遇到的第一个大坑我在第五章会专门给出完整配置。4. 数据库设计从 E-R 图到建表语句4.1 实体关系拆解五张核心表这个系统的表结构不算复杂核心表一共五张allusers管理员/用户表、fangwuxinxi房源信息表、gonggaoxinxi公告信息表、yonghu用户表、zulindingdan租赁订单表。合同信息表hetongxinxi和收藏表shoucang在部分实现版本里有但最基础的版本里合同信息通常是挂在订单下面的收藏功能则挂在用户中心里。先说allusers表。这张表很典型它的设计思路是「用户和管理员共用一张表」靠cx字段来区分角色——cx值为「管理员」时就是管理员值为「普通用户」时就相当于一个用户账号表。这种设计在课程设计里非常常见好处是登录逻辑统一只要查一张表就能完成角色判断坏处是字段会冗余——用户表里有身份证、手机这类字段管理员行里这些字段只能是空的。再看fangwuxinxi房源表它字段非常多房间号、房屋名称、房屋类型、图片、房型、面积、月租金、咨询电话、地区、详细地址、详情、状态。这里最容易踩坑的是「房屋类型」——它是直接存在房源表里的字符串比如「整租」「合租」而不是单独建一张fangwuleixing类型表再由房源表存类型 ID。这种设计在小项目里无所谓但如果后续要做「按类型筛选房源」字符串匹配的效率是不如 ID 关联的。我建议改造时把它拆成两张表。4.2 核心建表语句与字段级说明这里给出我在拆解过程中整理的标准建表语句基于资源里的表结构加上必要的注释。数据库字符集建议用utf8mb4避免中文乱码-- 管理员/用户共用表 CREATE TABLE allusers ( id INT(11) NOT NULL AUTO_INCREMENT, username VARCHAR(50) DEFAULT NULL COMMENT 用户名, pwd VARCHAR(50) DEFAULT NULL COMMENT 密码, cx VARCHAR(50) DEFAULT NULL COMMENT 角色标识管理员/普通用户, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT管理员/用户共用表;这段建表语句的逻辑非常简单三列加一个自增主键。cx字段是后加进去的所以放在最后。AUTO_INCREMENT 一定不能丢因为这个项目的 DAO 层在新增记录时依赖数据库自增生成的 ID如果你换成了手动赋值主键那插入逻辑全部要改。-- 房源信息表核心业务表字段最多 CREATE TABLE fangwuxinxi ( id INT(11) NOT NULL AUTO_INCREMENT, addtime VARCHAR(50) DEFAULT NULL COMMENT 录入时间, fangjianhao VARCHAR(50) DEFAULT NULL COMMENT 房间号, fangwumingcheng VARCHAR(50) DEFAULT NULL COMMENT 房屋名称, fangwuleixing VARCHAR(50) DEFAULT NULL COMMENT 房屋类型, tupian VARCHAR(50) DEFAULT NULL COMMENT 图片路径, fangxing VARCHAR(50) DEFAULT NULL COMMENT 房型 如一室一厅, mianji VARCHAR(50) DEFAULT NULL COMMENT 面积, yuezujin VARCHAR(50) DEFAULT NULL COMMENT 月租金, zixundianhua VARCHAR(50) DEFAULT NULL COMMENT 咨询电话, diqu VARCHAR(50) DEFAULT NULL COMMENT 地区, xiangxidizhi VARCHAR(50) DEFAULT NULL COMMENT 详细地址, xiangqing VARCHAR(50) DEFAULT NULL COMMENT 详情描述, zhuangtai VARCHAR(50) DEFAULT NULL COMMENT 状态未出租/已出租, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房源信息表;房源表的字段类型全部用了varchar(50)这看起来不太「规范」——面积和月租金按理说应该用int或decimal。但这不是错误而是毕设项目里一种「减少类型转换报错」的偷懒写法用字符串存所有字段页面取值后直接显示不需要在 Java 代码里做类型转换。代价是排序和范围查询会出问题比如按租金从低到高排序时字符串排序会出现「1000 200 30」这种结果。如果你想在原项目基础上加个「按租金排序」的功能强烈建议把yuezujin改成DECIMAL(10,2)。-- 租赁订单表包含审核状态 CREATE TABLE zulindingdan ( id INT(11) NOT NULL AUTO_INCREMENT, addtime VARCHAR(50) DEFAULT NULL COMMENT 订单创建时间, dingdanbianhao VARCHAR(50) DEFAULT NULL COMMENT 订单编号, fangwumingcheng VARCHAR(50) DEFAULT NULL COMMENT 房屋名称, fangwuleixing VARCHAR(50) DEFAULT NULL COMMENT 房屋类型, yuezujin VARCHAR(50) DEFAULT NULL COMMENT 月租金, zulinshijian VARCHAR(50) DEFAULT NULL COMMENT 租期时长, zongzujin VARCHAR(50) DEFAULT NULL COMMENT 总租金, beizhu VARCHAR(50) DEFAULT NULL COMMENT 备注, zulinriqi VARCHAR(50) DEFAULT NULL COMMENT 租赁日期, yonghuming VARCHAR(50) DEFAULT NULL COMMENT 下单用户名, xingming VARCHAR(50) DEFAULT NULL COMMENT 用户姓名, shouj VARCHAR(50) DEFAULT NULL COMMENT 用户手机, sfsh VARCHAR(50) DEFAULT NULL COMMENT 审核状态待审核/通过/拒绝, shhf VARCHAR(50) DEFAULT NULL COMMENT 审核回复内容, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT租赁订单表;这条建表语句揭示了一个关键设计订单表里冗余存储了用户名、姓名、手机号而不是通过用户 ID 去关联查询用户表。这是毕设项目里典型的「空间换时间」——查订单列表的时候不需要 join 用户表一次查询全出来。这种设计在职场上会被 DBA 批评但在课程设计里反而是加分项因为它让页面渲染逻辑简单了很多。你只需要记住如果用户改了手机号历史订单里的手机号不会跟着变这在业务上是不合理的答辩时如果被问到解释为「订单快照」即可。4.3 数据字段规范化与索引建议项目原表里所有字段都是varchar(50)这让整张表看起来非常「宽松」。但对于一个课程设计项目来说这种设计最大的优点就是不会出类型转换异常——表单传过来是什么字符串数据库就存什么字符串JSP 取出来直接显示。如果你不想大改保持原样是安全的如果你想让这个项目在答辩时更像「工程化」一点可以按下面的方向做最小改动第一把yuezujin和zongzujin改成DECIMAL(10,2)mianji改成DECIMAL(5,2)。这两个改动的收益最明显——租金排序、租金区间筛选、总租金计算都能直接做。第二在zulindingdan表的yonghuming字段上加普通索引因为用户查自己的订单是最频繁的查询路径加索引后数据量过万时能感受到明显差异。第三在fangwuxinxi表的zhuangtai字段上加索引因为前台首页默认查询是「状态为未出租」的房源这个字段会高频出现在 WHERE 条件里。但加索引这个事情在数据量只有几十条时是感觉不到差异的甚至会让插入变慢。所以这里有一个使用资源的「边界认知」如果你的毕设数据量就是演示用的一两百条原样建表就行不要花时间做索引优化。如果打算做压测或者扩展到几千条数据那就按上面三步走。5. 核心功能实现登录、订单与审核5.1 管理员登录的 JSP 处理逻辑登录功能是整个系统最基础也最重要的模块。它的实现思路是login.jsp页面的表单提交用户名和密码到后台ServletServlet里连接数据库从allusers表查询匹配记录成功则把用户信息存入session并跳转失败则返回登录页并提示错误。来看核心代码// LoginServlet.java 核心登录校验逻辑 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 获取表单提交的用户名和密码 String username request.getParameter(username); String password request.getParameter(pwd); // 连接数据库查询用户 Connection conn DBUtil.getConnection(); String sql SELECT * FROM allusers WHERE username? AND pwd?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs ps.executeQuery(); if (rs.next()) { // 登录成功把用户名和角色存到 session HttpSession session request.getSession(); session.setAttribute(username, rs.getString(username)); session.setAttribute(cx, rs.getString(cx)); // 角色 // 根据角色跳转到不同页面 if (管理员.equals(rs.getString(cx))) { response.sendRedirect(admin/index.jsp); } else { response.sendRedirect(index.jsp); } } else { // 登录失败回到登录页并带错误信息 request.setAttribute(error, 用户名或密码错误); request.getRequestDispatcher(login.jsp).forward(request, response); } }这段代码第一次看可能觉得绕但每一行都有它的作用。PreparedStatement相比Statement的优势是防 SQL 注入——登录接口是对外暴露的如果直接用字符串拼接 SQL输入 OR 11会被当成条件绕过密码验证这是最基本的 Web 安全常识答辩时十有八九会被问到所以这里直接用PreparedStatement是最稳妥的写法。跳转逻辑里要注意sendRedirect和forward的区别。登录成功用sendRedirect因为要告诉浏览器「重新发起一个新的请求去访问目标页面」这样浏览器的地址栏会变成目标页面的地址刷新页面时不会重复提交登录表单。登录失败用forward因为错误信息要存在 request 里传给 JSP 页面展示如果用了sendRedirectrequest 里的error属性就丢了。这个区别是 JSP 开发里最经典的面试考点之一也是很多人功能「感觉上不对」的根源。5.2 房源列表页面的条件查询实现前台首页的房源列表是这个系统最先展示给用户看的功能。实现方式是在index.jsp里嵌套 Java 代码片段直接调用 DAO 查询房源表并循环输出。它的查询逻辑有一个细节值得关注默认只显示状态为「未出租」的房源而不是全量显示。// FangWuDao.java 查询可租房源 public ListFangWu selectAvailable(String type, String keyword) { ListFangWu list new ArrayList(); // SQL 拼接基本条件 可选过滤条件 String sql SELECT * FROM fangwuxinxi WHERE zhuangtai未出租; // 如果选择了房屋类型追加类型过滤 if (type ! null !type.equals()) { sql AND fangwuleixing type ; } // 如果输入了关键词按房屋名称模糊查询 if (keyword ! null !keyword.equals()) { sql AND fangwumingcheng LIKE % keyword %; } sql ORDER BY id DESC; // 最新发布的排在前面 // ... 执行查询并封装成 FangWu 对象返回 }这段代码用的是字符串拼接 SQL这在前面的登录代码里我特意强调要用PreparedStatement为什么这里没用因为这里是条件查询条件数量不固定——有可能只传类型、只传关键词、也可能都传或都不传用PreparedStatement需要动态拼?占位符代码会变长不少。课程设计项目里用字符串拼接属于「能跑就行」的范畴但如果答辩时被问到 SQL 注入你可以回答说这里后续会统一改成PreparedStatement方式。这个查询结构里有一个小坑需要提醒ORDER BY id DESC用在字符串拼接 SQL 里没问题但如果你在 MySQL 8.0 里执行id是自增主键排序结果和按添加时间排序一致。可如果你的数据是从别处导入的ID 顺序不等于时间顺序那展示顺序就会「乱」。解决办法是按addtime排序但注意addtime在表里是varchar类型排序结果不是时间顺序而是字典序会得到完全错误的结果。这个项目在测试数据量小时看不出来但数据一旦超过 10 条且日期跨月就容易出现「9 月排在 10 月前面」的诡异顺序。5.3 租赁订单的提交与审核闭环租赁订单是连接「用户」和「管理员」的核心业务数据。流程是这样的用户在前台房源详情页点击「我要租房」系统把房源信息、当前用户信息组合后插入zulindingdan表订单状态为「待审核」管理员进入后台的租赁订单管理页面看到待审核订单确认没问题后点击「通过」订单状态变为「已确认」同时可以填写审核回复。这里直接看订单插入的核心代码// ZuLinServlet.java 用户提交租赁订单 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 从 session 中获取当前登录用户 HttpSession session request.getSession(); String yonghuming (String) session.getAttribute(username); // 从表单或隐藏域获取房源信息 String fangwumingcheng request.getParameter(fangwumingcheng); String yuezujin request.getParameter(yuezujin); String zulinshijian request.getParameter(zulinshijian); String zulinriqi request.getParameter(zulinriqi); // 计算总租金月租金 × 租期月数 String zongzujin calculateTotal(yuezujin, zulinshijian); // 插入订单表初始审核状态为「待审核」 String sql INSERT INTO zulindingdan (dingdanbianhao, fangwumingcheng, fangwuleixing, yuezujin, zulinshijian, zongzujin, zulinriqi, yonghuming, sfsh, shhf) VALUES (?, ?, ?, ?, ?, ?, ?, ?, 待审核, ); // ... 执行插入 }我们看一下dingdanbianhao订单编号是怎么生成的资源里用的是System.currentTimeMillis()加随机数的方式比如20250407153000123。这个生成方式在单机小项目里完全够用但注意不要用 UUID因为 UUID 是无序字符串在后台按编号搜索订单时没法用范围查询而且显示也不好看。还有一个非常关键的细节订单插入后管理员「通过审核」的动作是否正确同步了房源状态。业务上正确的逻辑是订单审核通过 → 房源状态从「未出租」改成「已出租」。这个操作在原项目里是分开做的——管理员先改订单状态然后去房屋信息管理里手动改房源状态。这是流程设计上一个可以改进的点如果你在改zulindingdan的sfsh字段时用一条 UPDATE 同时更新fangwuxinxi的zhuangtai字段就能实现业务闭环不用管理员做两步操作。这在答辩时是很好的加分点因为说明你想到了事务一致性。5.4 合同信息的生成与展示当订单审核通过后系统应该生成一条合同记录包含租客信息、房东信息、房屋信息、租期、租金等关键内容。在原项目里合同信息不是一个独立的录入界面而是管理员在订单详情页确认后自动生成的快照。字段包括合同编号、房屋名称、用户名、租期、租金、签订日期等。在 JSP 里展示合同详情时有一个使用资源时常见的需求让用户在前台能看到自己所有历史合同的列表。实现方式就是一个简单的商品表查询按用户名过滤SELECT * FROM hetongxinxi WHERE yonghuming 当前登录用户名 ORDER BY id DESC这个查询本身没有难度但在实际使用中你会发现合同表里存的是「用户名」而用户个人信息比如手机号存在yonghu表里。如果你要在合同列表页显示用户的手机号就必须做表关联查询。很多初次做这个功能的人会在 JSP 页面里嵌套 Java 代码循环列表的同时再查一次用户表这样会产生 N1 次查询数据量小没事数据量大了性能就很差。更优雅的做法是在 DAO 层用一条 LEFT JOIN 把查询拼出来一次取完所有字段。这也是改造时性价比很高的一个点。6. 避坑指南与常见问题排查6.1 JDBC 驱动加载失败ClassNotFound 报错现象Tomcat 一启动访问任何页面都报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver项目直接无法运行。原因这是 90% 的初学者跑 JSP MySQL 项目时遇到的第一道坎。项目里虽然写了数据库连接代码但 MySQL 驱动 jar 包没有放到 WEB-INF/lib 目录下或者放的是旧版驱动类名对不上。在 MyEclipse 里很多人把 jar 包放到了构建路径上但那只是编译时能找到运行时 Tomcat 根本不会去项目外部目录加载。解决把mysql-connector-java-5.1.49.jar或 8.x 版本对应的驱动 jar 包复制到项目的WebContent/WEB-INF/lib/目录下然后在 MyEclipse 或 IDEA 里执行「Refresh」让项目重新加载。另外检查驱动类名5.x 版本用com.mysql.jdbc.Driver8.x 版本必须改成com.mysql.cj.jdbc.Driver。确认一下你用的连接池如果是 C3P0 或 DBCP它们的配置文件里也要同步修改。6.2 Tomcat 启动闪退或端口被占用现象点击 Tomcat 启动按钮后控制台没有任何输出或者报Port 8080 was already in use服务起不来。原因第一8080 端口已经被其他程序占了最常见的是之前残留的 Tomcat 进程或者别的 Web 服务第二JDK 环境变量没配好Tomcat 的启动脚本找不到JAVA_HOME启动脚本直接失败退出。解决先用命令行查看端口占用情况netstat -aon | findstr 8080找到占用进程的 PID 后用taskkill /F /PID 进程号强制结束。如果是 JAVA_HOME 问题检查环境变量里JAVA_HOME是否指向 JDK 安装目录不是 JRE 目录并且在Path里加上%JAVA_HOME%\bin。在 IDEA 里启动 Tomcat 时注意配置「Run Configuration」里的 Application Server 路径不要让 IDE 和系统环境变量打架。6.3 中文乱码页面、数据库两头堵现象页面上显示的中文全是问号或乱码或者往数据库插入中文后查出来是???。原因乱码问题在 JSP 项目里几乎必现根源是「请求编码、响应编码、数据库编码」三处不一致。页面文件本身的编码是 UTF-8Tomcat 接收请求时默认用 ISO-8859-1 解码数据库默认字符集可能是 latin1三处对不上中文必然乱。这个坑在拆这个资源时我反复遇到因为varchar(50)存中文完全没问题关键是传递过程中解码错误。解决三步走。第一在每个 JSP 页面顶部加% page contentTypetext/html; charsetUTF-8 pageEncodingUTF-8%保证页面输出是 UTF-8。第二在获取请求参数之前执行request.setCharacterEncoding(UTF-8)让 Tomcat 用 UTF-8 解码表单数据。第三MySQL 建库时指定字符集CREATE DATABASE fangwu DEFAULT CHARACTER SET utf8mb4;。如果已经建库了用ALTER DATABASE fangwu CHARACTER SET utf8mb4;改库默认字符集再对已有表执行ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4;。6.4 SQL 语法错误在审核状态更新时出现现象管理员在后台点击「通过审核」按钮页面报SQLException: You have an error in your SQL syntax但仔细看 SQL 感觉没写错。原因这个项目里订单表有zulindingdan和hetongxinxi两张表如果你在写 UPDATE 语句时把一个字段名的中文别名或注释直接拼进了 SQL 字符串里MySQL 会把这个非法字符当成语法的一部分。另外一个经常犯的错是sfsh是 varchar 字段但你把值写成了数字1而没有加引号MySQL 在严格模式下会报错或者自动转换出警告。解决把 UPDATE 语句打印到控制台直接复制到 MySQL 客户端里执行一遍看具体的报错位置。这种「先把 SQL 打印出来」的习惯是我处理这个项目排障时最常用的一招——花 10 秒打印 SQL比猜半天的效率高得多。同时检查更新逻辑里给字符串值加单引号像已通过必须写成sfsh 已通过不能写成sfsh 已通过。6.5 文件上传与图片路径失效现象管理员在发布房源时上传房屋图片当时显示正常但重新部署项目后图片全部裂开或者换了一台电脑访问就找不到图片。原因图片上传功能的实现方式是把文件保存到项目部署目录下的某个文件夹里比如WebContent/upload/。当你重新部署 Tomcat 或者清理 work 目录时Tomcat 可能会把整个项目目录重建上传的图片文件就丢了。另外一个常见问题是保存到数据库的图片路径是绝对路径比如D:\upload\a.jpg部署到服务器后路径完全不匹配自然加载不到。解决先把图片统一存到一个不受 Tomcat 重部署影响的目录比如D:\upload\这种绝对路径然后通过配置虚拟路径映射来访问。在 Tomcat 的server.xml里加Context docBaseD:\upload path/upload reloadabletrue/这样页面里写/upload/a.jpg就能正常访问。如果不想动 Tomcat 配置那就把上传目录放在 WebContent 以外的地方用 IO 流的方式复制CDN 或对象存储方案不在课程设计范围内不做推荐。核心原则是上传路径和访问路径要一致并且不能依赖 Tomcat 的临时目录。6.6 时间字段的类型混乱现象订单列表里「租赁日期」显示出来是Wed Apr 07 00:00:00 CST 2025这种格式或者是2025-04-07 00:00:00.0看起来非常奇怪。原因表字段设计的坑——zulinriqi建表时是varchar类型但 Java 里取出来后若经过getTimestamp()或某些 ORM 框架处理它会被转成java.sql.Timestamp的对象直接toString()输出就是Wed Apr 07 00:00:00 CST 2025这种格式。项目里源码和表结构不一致的地方最容易出这种问题。解决如果你确认表里存的是字符串日期那 Java 代码里就用rs.getString(zulinriqi)直接按字符串取不要走getDate或getTimestamp。如果你想要标准输出格式在 SQL 语句里就用DATE_FORMAT(zulinriqi, %Y-%m-%d)格式化后直接返回字符串页面上就能直接显示。我第一次跑这个项目时就是被这个「varchar 里存日期然后用 Date 类型取」的写法规矩坑了一次花了大半小时看时间其实就改一行代码的事。7. 跑通之后的进阶改造与答辩亮点7.1 从 JSP 版本平稳迁移到 Spring Boot MyBatis如果你准备把这个项目作为毕设并且想冲一个不错的成绩我强烈建议在跑通原始 JSP 版本之后试着把它迁移到 Spring Boot MyBatis Thymeleaf 的架构上。迁移不是重写而是按层平移JSP 页面换成 Thymeleaf 模板或者直接用 Vue 接口分离Servlet 里的逻辑拆分到 Controller、Service、Mapper 三层共用的数据库连接工具类换成 MyBatis 的连接池管理。这个过程能帮你把「原来藏在 JSP 里的逻辑」彻底理清答辩时讲出来的东西会完全不一样。有一个非常具体的迁移路径推荐先迁移数据库层把 JDBC 直接操作换成 MyBatis 的 Mapper 接口这一步把原来 DAO 里的 SQL 语句原封不动搬进 XML 文件几乎不会遇到坑然后迁移 Controller 层把 Servlet 里的doGet/doPost逻辑拆成 Spring MVC 的GetMapping/PostMapping方法URL 保持和原来一致前台页面不用改最后再把 JSP 替换成 Thymeleaf这一步是最烦的因为 JSP 的% %脚本片段要逐段改成语法。做完这三步你对整个系统的理解深度会远超只交一份 JSP 版本的同组学生。7.2 可以低成本加分的三个功能点第一个是「房源状态自动变更」。刚才在第五章提到过订单审核通过后房源状态应该同步更新为「已出租」。加这段逻辑只需要在你处理审核通过的代码里补一条 UPDATE 语句但对业务闭环的理解是一个质的提升答辩时能主动讲出这条业务规则导师会认为你真正理解了系统。第二个是「合同编号的生成规则优化」。原项目的合同编号大概率是时间戳或者随机数如果你改成HT 年月日 当日订单序号的格式比如HT20250407003表面上是改一个字符串生成逻辑实际上展现了你是从「业务可读性」角度思考数据设计的这在答辩的延伸问题里是个安全的话题。第三个是「用户注册时对手机号格式做前端校验」。这个改动非常接底气因为在演示时老师很可能随手输入一个乱码手机号去注册如果你没校验他会觉得这个系统不安全加了正则校验后页面弹一下提示印象分会明显提升。代码就几行// 前端手机号格式校验JSP 页面的 script 片段 function validatePhone() { var phone document.getElementById(shouji).value; // 正则1 开头第二位 3-9共 11 位数字 var reg /^1[3-9]\d{9}$/; if (!reg.test(phone)) { alert(请输入正确的手机号); return false; // 阻止表单提交 } return true; }这段 JavaScript 放在注册表单的form onsubmitreturn validatePhone()里即可实现成本只有几行。虽然它只是前端校验后端依然需要再做一遍但作为课程设计已经够用了。我在答辩现场见过太多人系统功能完整但「注册表单随便乱填都能过」一两分钟就暴露了设计的粗糙程度给老师的印象分会打折扣。7.3 如何验证整个系统是可用的跑通后的验证不能只点一遍菜单就结束。我的习惯是走一条完整的业务链路注册一个新用户 → 登录 → 浏览公告、查看房源详情 → 收藏一个房源 → 提交一个租赁订单 → 退出登录 → 换成管理员登录 → 查看用户管理、审核订单 → 确认订单通过 → 查看合同是否生成 → 再到前台看这个房源的状态是否变成「已出租」。这一圈走完整个系统的主要功能就全部验证到了而且能第一时间暴露审核状态同步之类的问题。数据库层的验证也建议做一遍——用 Navicat 或 MySQL 命令行导出整个库看allusers、yonghu、fangwuxinxi、zulindingdan、gonggaoxinxi这几张核心表的数据是否完整对应。重点检查两点一是订单表和合同表的记录数是否匹配每个通过审核的订单都应有一条合同记录二是房源表里被租赁的房源zhuangtai是否被正确改成「已出租」。这两点是对应的缺一个都说明审核逻辑有问题。从那以后我接手任何 JSP/Servlet 相关的毕设资源都会强制走一遍这个「用户下单 → 管理员审核 → 状态联动」的完整链路再做数据库对账——这个习惯帮我拦截了至少五个「表面能用、一追业务就对不上」的项目问题希望也能帮你少走弯路。本文还有配套的精品资源点击获取