JSP房产中介系统实战：环境配置、数据库设计与部署调试全解析-平芜编程栈

1. 项目概述与需求拆解：这个JSP房产中介系统到底在解决什么问题

先聊聊这个项目本身。JSP房产中介管理系统，典型的Java Web课程设计/毕业设计项目，标题里带个“j32r6”——这类编号一般是开发者内部的项目版本标识，不用太关心它具体代表什么，你就把它当成“一套完整可交付的房产中介业务系统”的代号即可。

前几年我接过不少这种项目的调试部署工作，也在实验室带过几个小组去做类似的系统，对这个业务场景可以说很熟。房产中介的日常工作，说白了就是围绕“房源”和“客户”两件事转：收房、录房、挂房、找客户、带看、撮合、成交。这里面涉及的信息流是相当杂的——一个房源有户型、面积、朝向、楼层、租金/售价、出租/出售状态；一个客户有需求类型、预算区间、区域偏好；中间还有预约看房、成交记录、员工操作归属。如果全靠Excel和微信群，那混乱程度可想而知。

这套系统解决的核心问题，就是把这个线下流程搬到线上，让管理员和业务员能在Web端统一管理房源和客户信息，记录每一个预约和成交节点。从大部分实际项目的功能清单来看，它通常包含以下几个模块：

管理员登录、员工账号管理
房源信息管理（录入、修改、删除、上下架、条件检索）
客户信息管理（登记、跟进、需求记录）
预约看房管理（创建预约、确认状态、记录反馈）
成交管理（成交登记、成交列表）
基础的数据统计（房源数量、成交数量）或者简单的图表展示

总结下来，这个项目覆盖的是一个完整的轻量级信息管理系统闭环。你的增删改查、分页、模糊搜索、关联表查询、会话管理，这些Java Web阶段的核心知识点全都能在它上面找到落脚点。

适合谁来参考？如果你是正在做毕业设计或者课程设计的学生，选这个题目有两个天然好处：第一，业务模型不复杂，逻辑清晰，容易讲清楚；第二，JSP+Servlet+JavaBean是很多高校Java Web课程的教学主线，写完这个系统，你的课设答辩基本不用慌。如果你是刚学完Java Web、想找一个综合练习项目的开发者，这个系统同样是很好的练手对象——它不像电商项目那样大而全，但麻雀虽小五脏俱全，能帮你把从前端页面到后端数据库的整条链路走通。这篇文章就按我实际调试部署这类项目的完整流程来写，从技术选型、环境准备，到数据库设计、源码结构、具体跑起来的每一步，以及我踩过的那些坑，全部铺开讲明白。

2. 技术栈选型与环境准备：为什么这套老组合至今还能打

讲到“开发环境”，很多同学就头疼，因为就拿不到手的教材来说，版本信息五花八门，装环境全靠运气。我先给出一套我在多次部署中验证过的稳定版本组合，再逐个解释为什么这么选。

2.1 推荐环境版本组合

组件	推荐版本	说明
JDK	1.8（8u201以上）	稳定、兼容性好，Tomcat 8/9都完美支持
Tomcat	8.5.x 或 9.0.x	两个版本都能跑JSP/Servlet，8.5更经典
MySQL	5.7.x	5.7最稳，8.0也能用但要注意驱动和时区问题
IDE	Eclipse 或 IntelliJ IDEA	建议IDEA，现在学生群体用得最多
数据库工具	Navicat 或 MySQL Workbench	导入SQL文件方便
JDBC驱动	mysql-connector-java-5.1.49	兼容5.7，配8.0需换8.x驱动

很多老项目的源码是依托Eclipse的结构写的（项目根目录直接就是src、WebContent这种布局），IDEA导入的时候，你选“New -> Project from Existing Sources”，把Web Content目录指对就行，这个操作细节后面章节详细讲。

2.2 版本搭配的逻辑

先说JDK为什么要卡在1.8。虽然现在JDK已经出到17甚至21了，但这类老项目的源码大多用了JDK 8时代的语法和API，加上Tomcat内置的JSP编译器对高版本JDK的反向兼容并不完美，如果你用JDK 17去部署老项目，经常会碰到“无法将类 X 转换为接口 Y”这种莫名其妙的编译期错误。说白了，没必要为了追新给自己添堵。JDK 8不是不能用，它在这个场景下就是“最不坏的选择”。

Tomcat选8.5或9.0，是因为它俩对Servlet 3.1/4.0规范支持很好，而老项目的web.xml头基本是Servlet 2.5或3.0时代的写法，这两个版本能向下兼容。如果你手头是Tomcat 10，那就得注意了——Tomcat 10默认走Jakarta EE命名空间，javax.servlet要改成jakarta.servlet，老项目直接跑会报ClassNotFoundException，这个坑后面问题排查部分也会讲。

MySQL 5.7是我个人的偏好。它的InnoDB引擎表现稳定，性能足够，而且市面上流传的项目SQL文件大部分是从5.x环境导出的。你用8.0也不是不行，但导入老SQL文件时更容易踩到排序规则、时区、认证插件这几个雷。

2.3 搭建环境的实操清单

如果你是从零开始搭环境，按这个顺序走：

安装JDK 8，配置好JAVA_HOME和PATH，命令行验证java -version
解压Tomcat（建议不装系统服务，直接在IDE里集成），确认bin/startup.bat能启动
安装MySQL 5.7，设置root密码，用Navicat连接测试
创建数据库实例，比如house_manage，字符集选utf8，排序规则utf8_general_ci
打开Navicat的“运行SQL文件”，把项目自带的house.sql或类似名称的数据库脚本导入
IDE里配置Tomcat Server，把项目部署到Tomcat上启动

这里有一个重要提醒：老项目的数据库脚本可能不是直接新建库，而是只导表。如果导入前没手动创建数据库，脚本里有可能会报“Unknown database”。因此你导入前务必先在Navicat里新建一个同名的空库。

3. 需求拆解与数据库设计：中介业务背后的表结构是怎么来的

做项目不能光会跑，还得能讲明白“为什么这么设计”。这部分带你把房产中介的业务模型拆细，看看数据库表是怎么一张张演化出来的，这也是答辩时老师最爱问的地方。

3.1 从业务流程图到数据表

先闭上眼睛想一下房产中介店里每天发生的事。员工A录入一套新房源，打开电脑把小区名、户型、面积、租价/售价填进去，选好状态“待出租”，保存。客户B走进店里说要找两居室、月租3000以内、最好靠近地铁，员工A在系统里登记了这个客户的需求。第二天客户B看中一套房源，员工A在系统里创建一个预约看房记录。看完房客户满意，双方谈好价格，成交，员工A登记一条成交记录并把房源状态改成“已出租”。

这一串流程，映射到系统里就是四张核心业务表加两张基础表：

t_admin或t_user：管理员/员工账号，保存登录名、密码、角色
t_house：房源表，保存房屋描述信息和上下架状态
t_customer：客户表，保存客户的联系方式和需求信息
t_appointment：预约表，关联房子和客户，带预约时间与状态
t_deal：成交表，记录最终成交价格和时间
有些项目还会扩展t_house_type、t_area之类的字典表

比如说我在一个真实的模拟项目X（某房产中介管理系统）里见到的表设计长这样：

CREATE TABLE `t_house` ( `id` int(11) NOT NULL AUTO_INCREMENT, `title` varchar(100) DEFAULT NULL COMMENT '房源标题', `type` tinyint(4) DEFAULT '0' COMMENT '0出租 1出售', `community` varchar(100) DEFAULT NULL COMMENT '小区名称', `area` varchar(50) DEFAULT NULL COMMENT '区域/地段', `house_type` varchar(30) DEFAULT NULL COMMENT '户型 如2室1厅', `square` double DEFAULT NULL COMMENT '建筑面积', `price` double DEFAULT NULL COMMENT '租金/总价', `orientation` varchar(10) DEFAULT NULL COMMENT '朝向', `decoration` varchar(30) DEFAULT NULL COMMENT '装修情况', `status` tinyint(4) DEFAULT '0' COMMENT '0未租售 1已租售 2下架', `add_time` datetime DEFAULT NULL COMMENT '录入时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

注意这里用tinyint来存类型和状态，而不是直接用字符串。好处是程序里好判断、节省空间，坏处是写SQL时需要记得每个数字代表什么。实战中我会在项目里加一个常量类或者枚举来兜住这些状态值，远比魔法数字写死在业务代码里要清爽。

3.2 表关联与查询逻辑

房源表和预约表是典型的一对多关系，一个房源可以被多次预约；客户表和预约表也是一对多。成交表和房源则是一对一的关系——一个房源一旦成交，相应的业务记录就该归档。在设计时通过外键或逻辑外键把house_id、customer_id串联起来。

查询逻辑上最核心的是一个综合检索SQL——按区域、户型、价格区间、状态去筛选房源。这种场景其实就是普通的带条件WHERE的动态SQL拼接：

SELECT * FROM t_house WHERE 1=1 AND area LIKE CONCAT('%', ?, '%') AND house_type = ? AND price <= ? AND status = 0 ORDER BY add_time DESC LIMIT ?, ?

老项目里喜欢用WHERE 1=1来规避动态拼接时WHERE和AND的前置问题，虽然不太优雅，但胜在简单直接，面试官也不会太追究。分页这块就看代码里怎么写了，有的是PageBean手动计算总页数，有的直接用limit偏移量，两种都能跑，但你要能在答辩时解释清楚参数的含义，尤其是从第几条到第几条。

3.3 写库设计给我留下的经验

这类项目实际写下来，我最想提醒的是两件事。第一，项目给的SQL脚本里面通常会预置几条演示数据——这是好事，导入后马上就能看到列表效果，不要手贱删光。第二，密码字段在演示项目里大多是明文存储，因为JSP阶段的课程设计一般不涉及加密那套，但如果你后期要扩展，至少对员工密码做一次MD5+盐哈希，不然项目交上去也会被老师挑刺。

4. 源码结构与核心逻辑解析：DAO、Servlet、JSP三层页面是怎么协作的

技术选型这块已经说清楚了，接下来把项目源码的骨架扒开看看。老项目虽然不像Spring Boot那样有严格的分层脚手架，但大多数用JSP+Servlet+JavaBean写的项目，底层逻辑也遵循一条清晰的主线：JSP负责展示，Servlet负责接收请求和控制跳转，DAO负责数据库访问，JavaBean（Model）负责数据封装。我在调试部署中遇到的很多“跑不起来”的问题，根源都是没搞清楚这条链路。

4.1 目录结构与包职责

一个典型的JSP项目源码目录长得像这样：

src/ com.xxx.dao BaseDao.java // JDBC基础连接和增删改查封装 HouseDao.java // 房源表操作 CustomerDao.java // 客户表操作 AppointmentDao.java // 预约表操作 AdminDao.java // 登录验证、用户管理 com.xxx.servlet LoginServlet.java HouseServlet.java CustomerServlet.java AppointmentServlet.java DealServlet.java com.xxx.entity House.java Customer.java Appointment.java Admin.java com.xxx.util DBUtil.java // 数据库连接工具 WebContent/ admin/ // 管理端JSP页面 css/ js/ images/ WEB-INF/ web.xml

看到这个结构，你应该能马上联想到业务层次：页面发起请求，web.xml里的Servlet映射根据URL把请求分发给对应的Servlet类，Servlet调DAO完成数据读写，然后把结果set到request域里，最后forward或者redirect到JSP页面渲染。

4.2 核心逻辑代码长什么样

我挑两段核心代码来说，第一段是数据库连接工具类。几乎所有这类项目的根都在这里，数据库连不上，后面全白搭。

public class DBUtil { private static final String DRIVER = "com.mysql.jdbc.Driver"; private static final String URL = "jdbc:mysql://localhost:3306/house_manage?useUnicode=true&characterEncoding=utf-8"; private static final String USER = "root"; private static final String PASSWORD = "123456"; static { try { Class.forName(DRIVER); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(Connection conn, PreparedStatement ps, ResultSet rs) { // 逐个关闭，释放资源 } }

注意URL上带着useUnicode=true&characterEncoding=utf-8，这是为了存中文不乱码。很多新手部署完项目发现中文全是问号，一半原因就是这个URL参数没写对，另一半是数据库表字符集没设对。如果数据库换成了MySQL 8.0，你还需要在URL后面追加&serverTimezone=Asia/Shanghai，同时驱动类名要换成com.mysql.cj.jdbc.Driver。

第二段是Servlet端的处理逻辑，以房源列表分页为例：

@WebServlet("/house/list") public class HouseServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("utf-8"); int pageNum = Integer.parseInt(request.getParameter("pageNum")); int pageSize = 10; HouseDao dao = new HouseDao(); List<House> list = dao.findByPage(pageNum, pageSize); int total = dao.count(); int totalPage = (total + pageSize - 1) / pageSize; request.setAttribute("list", list); request.setAttribute("totalPage", totalPage); request.setAttribute("currentPage", pageNum); request.getRequestDispatcher("/admin/house_list.jsp").forward(request, response); } }

这段逻辑学名叫Model 2模式（JSP+Servlet+JavaBean的经典MVC），核心思想是：JSP页面不直接连数据库，Servlet做中转站。好处是页面和Java代码低耦合，以后换掉前端也好维护。缺点也明显——项目一大，Servlet类的数量会爆炸，每个实体一套增删改查，代码重复太多。

4.3 JSP页面里的交互细节

JSP页面端的写法比较暴力，很多老项目直接在标签里写<% %>脚本片段，或者在HTML中嵌入<%= %>输出。我在实际使用中建议你重点看两件事：

列表页的“详情/修改/删除”按钮要带主键ID跳转，比如修改时href="house?action=edit&id=${house.id}"，后端根据action区分操作类型。
表单页的select下拉和radio选项，回显时要判断当前值是否与数据值相等，<c:if>标签或者三目运算符都能实现。

举个例子，房源状态的回显通常这么写：

<select name="status"> <option value="0" ${house.status == 0 ? 'selected' : ''}>未租售</option> <option value="1" ${house.status == 1 ? 'selected' : ''}>已租售</option> <option value="2" ${house.status == 2 ? 'selected' : ''}>已下架</option> </select>

如果你拿到源码发现它是纯脚本JSP而没有JSTL，那么你在部署到Tomcat时就要确认lib下包含了jstl.jar和standard.jar，否则页面上凡是用了标签库的地方都会报错。

4.4 老项目的“经典坏味道”与改进空间

实话实说，这类项目源码里常见的坏味道不少：SQL字符串拼接为主，PreparedStatement用得少；Servlet里直接new DAO，没有接口解耦；JSP页面还穿插业务逻辑。但这不全是坏事，正因为结构原始，才更方便教学和二次改造。你在答辩时可以自己提出改进方向，比如把硬编码的数据库配置抽到properties文件里，把DAO层的公共操作提取成BaseDao泛型，把密码改成MD5加密存储。这些都是拿得上台面的加分项。

5. 完整调试部署流程：从拿到源码到系统跑起来，一步一步来

现在进入这篇博文的实操重头戏：如何把“程序+源码+数据库”这套东西真正部署成功。这一步我判断是绝大多数用户的拦路虎，因为环境问题五花八门，每个版本组合都有自己的小脾气。下面是一套经过多次验证的流程，按顺序执行，大概率一次跑通。

5.1 准备工作清单

在你开始动手之前，先把下面这几样东西准备好：

项目压缩包（里面应包含src源码、WebContent页面、SQL脚本、README或部署文档）
JDK 8安装包
Tomcat 8.5压缩包
MySQL 5.7安装包
Navicat或者MySQL Workbench
IDEA或者Eclipse

注意：老项目自带的README如果写着“需要MyEclipse”之类的备注，那只是个历史包袱，不用怕，IDEA完全能处理这些项目。

5.2 步骤一：导入数据库脚本

打开Navicat，左侧连接你本机的MySQL，右键“新建数据库”，名字用脚本里写的库名（打开SQL文件第一行能看到），字符集选utf8、排序规则utf8_general_ci。然后右键这个新库选择“运行SQL文件”，定位到项目里的.sql文件，等待执行完成。

导入完成后，建议花一分钟快速检查几张表的记录数和字段值。很多项目的初始管理员账号就写在t_admin表里，你直接SELECT * FROM t_admin;就能看到明文或哈希的密码。

5.3 步骤二：IDEA导入项目并配置SDK

菜单选择File -> New -> Project from Existing Sources...
找到项目文件夹，选择之后，IDEA会让你选择“Import project from external model”，选Eclipse或直接Next（这是个历史包袱，一般选Eclipse导入方式能更好地识别.classpath）
一路下一步，直到Project SDK界面选JDK 1.8
等待IDEA索引完毕，确认项目左侧能展开src和WebContent目录

导入后要做两件关键配置：

右键项目 ->Open Module Settings，在Facets里把Web资源目录指向WebContent，如果IDEA没自动识别，就手动添加Web Facet
在Artifacts里确认生成了war exploded类型的包，输出目录的lib下要包含所有JDBC驱动JAR（通常是WebContent/WEB-INF/lib下已有）

5.4 步骤三：配置Tomcat并启动

打开Run -> Edit Configurations...
点左上角加号，选择Tomcat Server -> Local
在Server选项卡里配置Tomcat安装目录
在Deployment选项卡里点加号，选择Artifact，把刚才生成的war exploded加进去，Application context可以设成/house或者留空（注意：如果留空，访问路径就是/项目名_war_exploded，比较丑）
启动前先检查一下JRE选项，确保用的是JDK 8而不是IDEA自带的JBR
点运行，看Console输出

如果一切顺利，控制台会打出org.apache.catalina.startup.Catalina start和“服务器启动在XXX毫秒”的字样。这时打开浏览器访问http://localhost:8080/项目名/就能看到登录页。

5.5 步骤四：登录与功能冒烟测试

用刚才在t_admin表里查到的账号密码登录，进去后逐个点一遍：房源列表、添加房源、客户管理、预约管理、成交记录。每个页面刷新两次，确认没报500错误，列表数据也能正常加载。

冒烟测试要特别关注分页按钮和搜索功能。很多项目分页参数和搜索条件是叠加在一起的，如果你点击下一页后搜索条件丢失了，那是代码里没把keyword带过去，这是常见的小bug，但不是环境问题。

5.6 部署过程中那点致命的细节

这里有一个我用经验和教训换来的提醒：如果你使用的是IDEA自带的Tomcat集成，而不是手动解压一个Tomcat，那么项目部署到的是IDEA为你创建的一个临时副本目录。这意味着你之后在Tomcat的webapps目录下直接找不到项目文件。这不算问题，但会让你在改配置时找错地方，所以记住一个原则——修改项目配置就在IDE里操作，不要去临时目录里翻。

6. 常见问题与排查技巧实录：跑不起来，十有八九是这几个原因

部署老项目，我基本每次都会碰上几个经典问题。这一章把最高频的报错和对应的处理方式整理成速查表，按图索骥，能省下你不少排查时间。

6.1 问题速查表

现象	可能原因	解决方案
Tomcat启动失败，报端口被占用	8080端口已被其他进程占用	改Tomcat的server.xml里的端口，或关掉占用进程
浏览器404，提示源服务器未找到目标资源	项目部署路径和输入URL不匹配	检查IDEA的Application context和访问URL一致
访问页面报500，日志提示ClassNotFoundException	JDBC驱动JAR缺失	把mysql-connector的jar放到WEB-INF/lib，并确认Artifact里有它
连接数据库报Communications link failure	MySQL未启动、URL写错、账号密码错	先确认Navicat能连上，再比对DBUtil里的URL参数
控制台报UnsupportedClassVersionError	JDK版本过高/不匹配	把Project SDK和Tomcat JRE都切成JDK 8
页面中文乱码或问号	数据库字符集、连接URL、JSP编码不一致	三处统一为UTF-8，并检查数据库排序规则
登录成功但跳转后session丢失	浏览器禁用了Cookie	换浏览器测试，或检查Servlet里session处理逻辑
图片或上传文件无法显示	Tomcat的getRealPath在IDEA部署下指向临时目录	文件真实路径写死到项目的上传目录，或用虚拟目录映射

6.2 两个比较复杂但很常见的场景

第一个场景：项目页面上能出HTML，但是所有动态数据都不显示，日志里也没有任何报错。这种往往不是环境问题，而是SQL语句在旧版MySQL里执行失败，被try/catch吞掉了异常并返回了空集合。处理方法是把DAO层的关键方法临时加上e.printStackTrace()，把控制台打出来的SQL复制到Navicat里手动执行一遍，看是表名写错还是字段不匹配。这一步能定位90%的“页面空白”问题。

第二个场景：Tomcat 8.5跑老项目报各种javax.servlet相关类找不到。先看web.xml头部版本，如果写的是XSD 2.5或3.0，那Tomcat 8.5是没问题的；如果你用的是Tomcat 10+，就明白问题出在命名空间迁移上了，要么降Tomcat到9.0，要么全局替换源码里的javax.servlet为jakarta.servlet。对于这种老项目，我的建议永远是降级Tomcat，而不是改源码。

6.3 避坑经验总结

我再提三条相对冷门但实用的经验。第一，老项目的WEB-INF/lib里如果已经有了旧版JDBC驱动，你在本地又放了一份新版驱动到别的lib目录，启动时可能因为类加载顺序不同而用错驱动，所以项目里只保留一份驱动。第二，Tomcat部署时如果遇到“Docbase路径不存在”，通常是IDEA里Artifact输出目录没配对，回到Module Settings里把Facet的Web Resource Directory重设一下。第三，用Eclipse部署老项目时会自动生成.settings配置文件，如果你后续换到IDEA开发，建议删掉.settings、.classpath、.project三个文件再导入，避免IDE之间互相干扰。

7. 从能跑到能用：项目上看不到的扩展与性能优化思路

系统跑通之后，我的建议是你别急着交差，把下面几个点动手改一改。不需要推倒重来，增量改造即可，花半天时间就能做出来，但答辩时讲出的东西就完全不一样了。

第一件事是数据库连接池改造。现在项目里用的还是最原始的DriverManager.getConnection()，每次请求都创建连接、用完关闭，在高并发下性能堪忧。你可以引入Druid或者C3P0连接池，把连接配置放在druid.properties里，DAO从数据源拿连接。这是个经典加分项，而且代码改动量很小。

第二件事是密码加密。演示项目里t_admin表的密码大概率是明文，你可以引入MD5或SHA-256加盐的方案。登录时先哈希再比对，改动的核心代码也就一两个类，还能顺带学一下Java安全编程。

第三件事是前后端交互方式的演进。老JSP项目的表单向跳转刷新比较多，现代用户用起来体验确实一般。如果时间有限，不用重写，只需要引入一点原生Ajax或者Vue的局部渲染，把“删除”操作改成异步确认，把“状态切换”改成点击按钮即时更新——体验提升立竿见影。但注意，引入前端框架时，老项目不是Maven结构，依赖管理和打包方式要自己处理好，不要打成一团乱麻。

第四件事，如果你真的有时间把这个项目整体演进一次，我推荐的方向是：用Maven重构项目结构，从JSP页面 + Servlet逐步迁移到Spring Boot + Thymeleaf，或者Spring Boot + Vue的前后端分离。表面上这是技术栈迁移，本质上是同一个业务模型的工程化演变。你在迁移过程中会真正理解什么叫“分层清晰”，什么叫“接口设计”，这些东西是看再多的理论文章都换不来的。

我个人在实际操作中的体会是，很多同学拿到源码的第一反应是“把它跑起来就完了”，但这个心态容易让你错过这个项目80%的价值。老项目好在结构简单、没有框架的魔法和黑盒，你可以在源码里看到最原汁原味的JDBC代码、Servlet代码、JSP页面，一眼就能看懂一个Web请求从浏览器到数据库再回到浏览器的完整旅程。你把这个旅程走通，再回头看Spring Boot里的@Controller、@Service、@Repository那套，会发现它只不过是把这段旅程里的通关节点用注解重新标注了一遍。

最后再分享一个小技巧：做这类系统，你交付的时候最好配一张业务流程图和一张数据库ER图，不一定要画得多专业，哪怕是手写的整理稿也行。等你讲完这两个图，再演示系统里的房源检索和预约流程，整个项目的完整度和可信度瞬间就不一样了。这套组合拳，我自己用过很多次，比单纯堆功能要有效得多。