基于Java Servlet的人才公寓客房预订系统开发全攻略

“基于Java Servlet的人才公寓客房预订系统”这种题目，在高校课设和毕业设计里出现的频率非常高，很多同学第一眼看到会觉得是一个老掉牙的“增删改查”项目。但从我实际带过多个类似模拟项目的经验来看，这类系统恰恰是最能检验Java Web基本功的试金石。Servlet + JSP + JDBC这套组合虽然看起来不够“现代”，但它把HTTP请求处理、会话跟踪、MVC分层、数据库事务这些最核心的底层逻辑全都摊开在桌面上，让你无法逃避任何一个细节。这篇文章我会从标题拆解、需求建模、数据库设计、核心模块实现到常见坑点排查，完整梳理一遍做这类系统的思路和实操过程，适合正在为选题头疼的同学，也想给那些习惯了Spring Boot全家桶却对底层机制发怵的开发者一些参考。

1. 项目整体拆解：从标题反推真实需求

先别急着建工程、写代码，拿到“基于Java Servlet 人才公寓客房预订系统”这个标题，第一步要做的是把标题拆开揉碎，搞清楚它背后到底承载了哪些业务诉求。我见过太多人一上来就设计七八张表、十几个页面，结果做到一半发现核心流程根本没跑通。

1.1 核心业务与服务对象解析

标题里有两个绝对不可忽略的关键词：一个是“人才公寓”，一个是“客房预订”。

“人才公寓”决定了系统的服务场景和用户群体的特殊性。它不是普通酒店，也不是长租平台的私人房源，而是地方政府或企业为引进人才提供的过渡性周转住房。这个定位意味着系统里必须要有房源类型管理（比如一居室、两居室、套间）、入住资格审核（非普通用户注册即订，需校验身份）、入住周期管理（通常有最长居住期限限制）等贴近人才公寓实际管理规则的业务逻辑。

“客房预订”则明确了系统的核心业务闭环：用户浏览房源→提交预订申请→管理员审核确认→办理入住→到期退房。围绕这条主线，才能合理地把系统拆分为前台用户端和后台管理端。值得注意的是，这里的“预订”不是简单的下单，它包含状态流转，预订申请提交后是需要人工审核的，这是人才公寓场景区别于商业酒店预订的典型特征。

1.2 功能边界与角色权限推演

从标题的“设计与实现”可以推断，这个系统至少需要覆盖两个角色：普通用户（公寓申请/预订者）和系统管理员（公寓运营方）。站在课设/毕设评审的角度，这两类角色下的功能矩阵基本就是项目的功能边界说明书。

普通用户端合理的功能切片，对照来看应该是这些：

• 注册与登录：手机号或邮箱注册，密码加密存储。
• 房源大厅浏览：按类型、状态、价格区间筛选，查看房源详情、实拍图、配套设施。
• 在线预订：填写入住时段、入住人数、申请说明，提交后等待审核。
• 我的预订列表：查看所有订单的状态（待审核、已通过、已驳回、已入住、已退房、已取消），在待审核状态下允许取消或修改。
• 个人中心：个人信息维护、密码修改。

管理员端的核心功能切片：

• 房源管理：房源信息的增删改查、上下架、录入真实图片或占位图。
• 预订审核管理：列出所有待审核申请，确认申请人资格后通过或驳回（驳回需填写原因）。
• 入住/退房管理：审核通过后房源状态自动变为已占用，办理退房后恢复可预订状态。
• 统计概览（加分项但强烈建议做）：今日预订数、当前入住率、房源类型分布等简单统计图表。
• 用户管理：查看注册用户列表，可对违规用户禁用/解禁。

整个系统的权限控制不需要做到像Spring Security那样精细，但至少要通过过滤器或拦截器实现：未登录用户不能访问个人中心，非管理员不能访问后台页面。

1.3 技术栈选择的合理性分析

在选择技术栈时，很多人会纠结：既然都是课设了，为什么不用Spring Boot？我的看法是，标题里明确写了“Java Servlet”，那就老老实实把Servlet这条技术线路吃透，用JSP + Servlet + JDBC + MySQL + Tomcat的经典组合来实现。这样做有几个实打实的好处：

第一，整套请求链路是透明的。一个请求从浏览器发出，经过Tomcat解析HTTP报文，调用Servlet的doGet/doPost，再通过DAO层访问数据库，然后数据回填到域对象中，最后转发到JSP渲染页面，每一步都有Engine的参与，没有任何“黑盒魔法”（比如自动配置、依赖注入）。做完这个项目，你对HTTP协议、请求生命周期、会话跟踪机制的认知深度，绝对比那些直接用框架对着视频敲出来的人要扎实得多。

第二，SQL能力和手工编码能力会得到强制锻炼。没有MyBatis/JPA帮忙自动生成SQL，所有SQL语句都需要自己手写，join、group by、子查询这些基本功根本逃不掉。

第三，答辩时有东西可讲。评审老师最喜欢问的问题就是“你这个Filter是干什么的？Session存在哪里？数据是怎么从数据库显示到页面上的？”——用纯Servlet实现的项目，这些问题每一个都可以拎出来从容应对。

2. 架构设计与数据库建模：动手写代码前的关键决策

代码不是项目的核心，合理的架构和数据结构才是。很多半途烂尾的项目，问题都出在一开始没想清楚分层和表结构。

2.1 分层思想落地：MVC与DAO模式应用

不要把所有逻辑都堆在Servlet里，也不要让JSP页面直接操作数据库（虽然确实有人这么干）。我建议按经典的分层架构来组织这个模拟项目的代码包结构：

com.demo.apartment ├── entity # 实体类：User, Room, Reservation等，与数据库表一一对应 ├── dao # 数据访问层：负责JDBC操作，封装增删改查 ├── service # 业务逻辑层：处理预订状态流转、校验等业务规则 ├── servlet # 表现层控制器：接收请求、调用服务、页面跳转 ├── filter # 过滤器：处理编码、登录校验、后台访问控制 └── util # 工具类：数据库连接池、字符串处理等

这种分层方式对应的是项目答辩时一个高频问题：“为什么要把DAO单独抽出来？”答案很简单：Servlet的主要职责是接收HTTP请求和决定跳转逻辑，如果里面写满了JDBC代码和SQL字符串，代码会变得极度臃肿且完全没办法复用。

举一个业务层的典型场景：用户提交预订时，系统需要做“检查房源是否可预订 → 计算总价 → 创建订单 → 若指定时间段无冲突则生成记录”这一连串操作。如果把这段逻辑写在Servlet里，整个方法会被塞得乱七八糟，而且并发情况下很容易出Bug。抽到Service层后，逻辑清晰，事务边界也容易把控。

2.2 数据库表结构关键设计思路

数据库设计是整个系统最重要的地基。结合前面的需求分析，最少需要四张核心表，我把字段设计和关键考量写一下：

• t_user（用户表）：id、username、password（这里如果只是课设级别，用MD5加盐后存储就够，但我会在后面的实操里推荐你直接在Java代码中做SHA-256加盐处理，避免被老师一问质询就露出破绽）、real_name、phone、role（0表示普通用户，1表示管理员）、status（启用/禁用）、create_time。

• t_room（客房表）：id、room_number、type（单间/一室一厅/两室一厅）、area、price（注意这里建议用DECIMAL而不是FLOAT或DOUBLE）、max_occupancy（最多入住人数）、facility（描述配套设施）、status（0空闲，1已预订，2已入住）、img_path（存放拼接后的图片路径）、description、create_time。

• t_reservation（预订记录表）：id、user_id、room_id、check_in_date、check_out_date、total_price、status（0待审核、1已通过、2已驳回、3已入住、4已退房、5已取消）、apply_reason、review_remark、create_time、review_time。这张表是整个系统的核心业务承载表。

• t_announcement（公告表，可选）：id、title、content、create_time。用于管理员发布公告，前端滚动展示，很小的功能，但在课设里非常讨彩。

下面我用一个简单的建表片段说明预订记录表的设计重点（注意时间字段类型、价格字段精度、索引设计）：

CREATE TABLE t_reservation ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, room_id INT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, total_price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1已通过 2已驳回 3已入住 4已退房 5已取消', apply_reason VARCHAR(500), review_remark VARCHAR(500), create_time DATETIME NOT NULL, review_time DATETIME, KEY idx_room_id (room_id), KEY idx_user_id (user_id), KEY idx_status (status), CONSTRAINT fk_res_user FOREIGN KEY (user_id) REFERENCES t_user(id), CONSTRAINT fk_res_room FOREIGN KEY (room_id) REFERENCES t_room(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

为什么状态字段要用TINYINT而不是直接用VARCHAR存“待审核”这样的中文？因为用数字表示状态，在Java里定义一个枚举类就能统一管理，页面显示时再统一翻译成对应的中文文案。避免了“待审核”和“待审核 ”这种带空格这类低级错误导致的状态判断Bug。

2.3 预订系统的状态机设计

上面那张预订表里我特意设计了状态字段，这是所有课设项目中容易被轻视但至关重要的一环。预订状态不是随意枚举的，它们之间存在合法的转换路径，这个逻辑必须先理清楚，代码才不会写成一团乱麻：

待审核 --> 已通过 --> 已入住 --> 已退房 待审核 --> 已驳回 待审核 --> 已取消 已通过 --> 已入住（用户实际办理入住后） 已入住 --> 已退房（到期或提前办理）

从这条状态流转线能看出，任何非法的状态跳转在业务层都应该被拦截。比如用户只能取消“待审核”或“已通过”状态的订单，管理员的审核操作只对“待审核”订单生效。这个约束不仅在后台代码里要写，前端表格的“取消预订”按钮也要根据当前状态做隐藏或禁用。

状态机的价值在于，它天然地防止了逻辑漏洞。我在帮某位同学看代码时，就遇到过一个问题：管理员把已入住的订单误操作成了已取消，导致一个房间凭空空出来又被别人预订了，这就是典型的没给状态流转上锁。提前把状态图画好，再对照着写if/else判断，基本不会出这种低级事故。

3. 核心模块代码实现：关键环节与避坑细节

这里我按实际开发中会遇到的顺序，从用户注册登录、房源展示到预订下单这个核心流程，展开说一下实现要点和容易踩的坑。

3.1 数据库连接管理与JDBC的封装

这往往是很多同学项目的第一个分岔路，也是在答辩时最容易被追问的地方，毕竟数据库连接是Servlet项目的数据基础。不要在每个DAO方法里独立获取连接，更不要用DriverManager直接写硬编码URL，一定要封装一个DBUtil工具类，尽量结合数据库连接池技术（课设级别首推Druid，依赖少、监控还要看，但更推荐直接用C3P0/HikariCP之一，因为后续好讲清楚）。

以一个简化版的DBUtil为例：

public class DBUtil { private static DataSource dataSource; static { try { // 读取类路径下的db.properties配置文件 Properties props = new Properties(); props.load(DBUtil.class.getClassLoader().getResourceAsStream("db.properties")); dataSource = DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError("数据库连接池初始化失败"); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } public static void close(ResultSet rs, PreparedStatement stmt, Connection conn) { // 依次释放资源，避免连接泄漏 } }

这里有两个细节必须注意：

第一，配置文件db.properties里url要加useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai。如果不加，中文数据入库后查出来变成问号、日期格式报错是必然的，这是编码问题中的第一个坑。

第二，关闭资源一定要遵循“先开的后关”原则，逐层判断是否为null再关闭。在课设项目里，数据库连接泄漏是导致后期系统越来越卡、最终直接报too many connections的罪魁祸首，这个问题会在答辩现场被老师一眼看出来。

3.2 登录与会话管理配置

用户登录是一个很基础但必须做完整的功能。处理流程是：JSP页面表单提交username和password到LoginServlet，在Servlet中先调用Service层校验，成功后把用户对象塞进Session，然后根据用户角色重定向到不同的首页。

进行这个业务时有两个必须注意的安全细节：

第一个是密码加密。无论你用什么加密算法，都不应该以明文密码存储。这里我建议的实操做法是：注册时用SHA-256(原始密码 + 盐)计算散列值存储，盐可以用UUID生成并随用户记录一起存储。校验时用相同的算法重新计算比对。既没引入第三方框架，答辩时又能堂堂正正地说自己考虑了安全问题。

第二个是防止会话固定攻击。登录成功后强烈建议调用request.getSession().invalidate()销毁旧Session再创建新Session，即“Session固定攻击防护”。这一步虽然是几行代码的事，但在课设项目中属于很值得展示的加分细节。

还有一个所有项目都绕不开的坑：过滤器的匹配顺序与登录校验页面跳转死循环。我写过一篇笔记专门聊过这个，核心问题是：你做了一个LoginFilter，把它映射到了“/*”，结果用户未登录访问login.jsp时也会被拦，然后重定向到login.jsp又触发了Filter拦截，造成无限重定向报错，浏览器直接提示“网页无法正常运作”。解决方案是配置放行规则，静态资源、登录接口、登录页面、注册页面明确放行，其余URL才进入登录校验。

@WebFilter("/*") public class AuthFilter implements Filter { private static final Set<String> PASS_URLS = new HashSet<>(Arrays.asList( "/login.jsp", "/register.jsp", "/user/login", "/user/register", "/css", "/js", "/images" )); public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI().substring(request.getContextPath().length()); if (PASS_URLS.contains(uri) || uri.startsWith("/css/") || uri.startsWith("/js/") || uri.startsWith("/images/")) { chain.doFilter(req, resp); return; } HttpSession session = request.getSession(false); if (session != null && session.getAttribute("loginUser") != null) { chain.doFilter(req, resp); } else { response.sendRedirect(request.getContextPath() + "/login.jsp"); } } }

这样改造后的实习生作品才真正具备答辩时“自动化”的水平，管理员后台的过滤也可以按类似思路单独写一个AdminFilter，或者在同一过滤器里加角色判断。

3.3 房源展示与前端页面交互

房源的列表展示需要考虑分页，这也是课设中出现频率极高的功能点。不要为了偷懒一次性查全表载入页面，用户量小的时候看不出来，一旦数据量上去了，不仅页面加载慢，评审老师也会直摇头。

我把分页的两种实现思路放在这里做个小对照：

在SQL层面，完成物理分页至少需要两个查询：一个是查指定页数据的SELECT ... LIMIT ?, ?，另一个是SELECT COUNT(*)算出总记录数以拼出页码条。这里最容易出现的错误是页面的“上一页/下一页”点击时页码参数忘记拼接，以及翻页时查询条件丢失。我建议用一个PageUtil工具类封装分页参数（当前页、每页条数、总记录数、总页数），然后把查询条件字段也放到一个Map里传给DAO层，这样每次翻页重新构建请求URL时会把条件自动带上。

房源详情页的图片处理也是常见的坑。实际操作时，不要直接上传图片文件到项目根目录，更不要存BLOB到数据库。规范做法是：在服务器上建一个独立的上传目录（例如D:/upload/room/），把用户上传的图片保存到该目录，数据库中只存放图片的相对路径，例如/upload/room/20250601_xxxx.jpg。页面通过配置虚拟路径映射（或在Tomcat的server.xml里加Context映射）来访问。这样做既避免了数据库膨胀，部署服务器时也更容易维护。

3.4 预订业务的并发安全处理

预订是整个系统中业务最重要的环节，同时也是并发问题最严重的地方。想象一个场景：一个热门房源剩余最后一个可预订间夜，用户A和用户B几乎同时点击“提交预订”，两条请求同时到服务端。由于Java Web默认的Servlet是单实例多线程的，两个请求完全可以同时执行“检查房间是否空闲”并同时都判定“有空闲”，然后同时创建订单，导致同一个房间被预订给两个人。

最常见的解决办法是“乐观锁 + 数据表唯一约束/条件更新”，如果只是课设级别的并发防护，可以直接使用同步代码块，或者干脆利用MySQL的SELECT ... FOR UPDATE行锁来串行化预订流程。代码层面是这样处理的：

public boolean createReservation(int roomId, Date checkIn, Date checkOut, int userId) { Connection conn = DBUtil.getConnection(); conn.setAutoCommit(false); try { // 1. 使用行锁锁定该房源记录，阻止其他事务同时修改 String lockSql = "SELECT status FROM t_room WHERE id = ? FOR UPDATE"; int roomStatus = execQueryOne(conn, lockSql, roomId); if (roomStatus != ROOM_AVAILABLE) { conn.rollback(); return false; } // 2. 校验指定时间段内是否已存在冲突的未取消订单（状态为已通过或已入住） String conflictSql = "SELECT COUNT(*) FROM t_reservation WHERE room_id = ? " + "AND status IN (1, 3) AND check_out_date > ? AND check_in_date < ?"; int conflictCount = execQueryCount(conn, conflictSql, roomId, checkIn, checkOut); if (conflictCount > 0) { conn.rollback(); return false; } // 3. 插入预订记录，同时把房间置为已预订（状态1）—— 或保持待审核后管理员统一处理 conn.commit(); return true; } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); DBUtil.close(null, null, conn); } }

这里有个重要的时间冲突判断：假设已有订单的入住时间是2025-07-01，退房时间是2025-07-10，新增的订单如果入住时间在2025-07-08、退房2025-07-09，那么check_out_date > ? AND check_in_date < ?两个条件都会被命中，成功拦截。但如果两端日期完全错开，则不会冲突。这个判断逻辑是预订类系统最常见的核心算法，务必理解。

课设中经常遇到的一个场景是事务管理与数据源连接绑定的问题。有人会发现，自己在Service方法里设置了conn.setAutoCommit(false)，但DAO层每次都通过DBUtil取了一个新连接，导致事务根本不起作用。所以一个通用经验是：用一个ThreadLocal保存当前线程绑定的Connection，DAO层从ThreadLocal中取连接参与事务，Service层统一开启/提交/回滚。这是我在此类课设项目里的必测检查项。

4. 常见问题与排查技巧实录

整个项目做到验收和答辩阶段，会遇到很多看似诡异、实则原因极其明显的问题。这里我整理几个高频坑，基本都是我在模拟项目中反复撞见的，值得拿出来单独说。

4.1 中文乱码问题全景分析

中文乱码可能是课设项目里出现频率最高的求助问题，没有之一。根源在于——Servlet、JSP、数据库三个阶段如果都没统一字符编码，链条上任意一环断掉，页面显示就会出现“??????????”或乱码方块。

下面这个排查顺序和解决方法是我个人处理该问题时的标准流程：

1. 请求编码：POST请求中如果包含中文，在Servlet里读取参数前执行request.setCharacterEncoding("UTF-8")。这个设置必须【、在任何getParameter调用之前执行才有效。

2. 响应编码：JSP页面顶部必须有<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>，同时也需要response.setContentType("text/html;charset=UTF-8")（如果用的是Servlet输出JSON或字符串）。

3. GET请求参数编码：POST请求按上面第1步设置就能解决，但GET传参的中文乱码与Tomcat的URIEncoding配置有关，需要在Tomcat的conf/server.xml中给Connector加上URIEncoding="UTF-8"。

4. 数据库编码：建表统一使用utf8mb4字符集；JDBC连接的URL上面已经提过，必须设置characterEncoding=utf8。

按这个顺序排查一遍，基本能解决九成以上的中文乱码问题。乱码问题一旦彻底解决，项目里的很多体验雷区就已经平掉了。

4.2 本地正常部署后页面404或图片不显示

这类问题的诱因通常不是代码逻辑错误，而是部署路径和资源位置不匹配。

• 如果404的是页面，检查WebServlet注解里的路径是否完整正确，以及JSP文件是否放在了webapp目录下的正确位置。遇到/list.jsp直接访问没问题但Servlet里forward到/room/list.jsp却404时，排查成路径是否多写或少写了目录，特别是WEB-INF目录下的JSP，浏览器无法直接访问，这是Java Web的默认规则。

• 图片不显示的首要排查方向是图片实际存放目录是否和数据库里的路径对得上。如果用IDEA配置虚拟路径，检查是否误把自定义上传目录配置到了target目录，因为每次clean和重新部署都会清空target目录里的上传文件。我自己踩过一次，根源就在这里。所以模拟项目建议把上传目录独立到项目外部，例如D:/upload/，然后为它单独加一个Context Mapping，用URL前缀/upload/**去映射物理路径，部署时才不会丢失文件。

4.3 SQL注入与打印SQL日志的自我检查技巧

纯JDBC项目上手时，很多同学为了省事直接拼接SQL字符串。比如代码写成：

String sql = "SELECT * FROM t_user WHERE username='" + username + "' AND password='" + password + "'";

这是非常危险的写法，会导致典型的SQL注入漏洞。一次答辩中可能有同学在登录框输入用户名' OR 1=1 --就成功登录了管理员账号，当场翻车。正确做法是永远用PreparedStatement占位符传参：

String sql = "SELECT * FROM t_user WHERE username = ? AND password = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password);

另一个关于SQL的实操习惯是调试阶段要打印SQL。在DAO层或工具类中临时加System.out.println(sql)可以快速定位语法错误。比如LIMIT ?, ?和PreparedStatement设置参数时，第一个符合条件的数据却是从1开始计数而不是0，如果你直接用页面传过来的页码填进去，就永远会错位掉第一页——总页数计算出错而且首页显示数据错乱。这是分页里一个特别常见的小坑，打日志能一秒看出来。

4.4 数据库连接查询导致的线程安全与资源泄漏

还有一个容易被忽略但答辩时可能被反复追问的问题：Servlet是单实例多线程的，如果在一个Servlet里声明了一个成员变量private Connection conn = DBUtil.getConnection();，接下来多个请求同时操作这个Servlet时会共用一个数据库连接，进而导致并发无法控制、事务混乱甚至连接中断。

正确做法是：永远不要在Servlet成员变量中持有数据库连接、用户状态等有状态资源，连接应该按需在DAO方法内获取，用完立即归还连接池；对于用户状态，放入Session域即可。

资源泄漏是另一个高频血泪教训。有些同学只关闭了ResultSet和Statement却忘记关闭Connection，在连接池环境下Connection并没有真正断开，只是归还了池子，频繁的资源再分配会让连接池崩溃。我提供的DBUtil中已经有了close方法，但在一个方法内多次查询时，每次反正都要“查询→关闭”是比较保险的习惯，不要想着批量复用。

5. 项目功能之外的加分思路与扩展建议

如果你做完核心流程还有余力，那么下面这些扩展方向是低成本高回报的，对答辩评分的提升非常明显。它们本质上没有跳出项目的默认范围，反而会更贴合“人才公寓”的业务场景。

5.1 管理端统计看板的简易实现

很多同学的课设最后一步就是管理后台的“房间列表管理”，做完就没下文了。其实只要多加一个页面，系统的完成度和“设计感”会瞬间上了一个台阶：在管理端首页增加一个统计区域，显示当日新增预订数、待审核订单数、当前公寓整体入住率、最受欢迎房源类型Top3。

统计SQL并不复杂，比如可以用一个SQL查出入住率：

SELECT COUNT(*) AS total_rooms, SUM(CASE WHEN status = 2 THEN 1 ELSE 0 END) AS occupied_rooms FROM t_room;

再用一个SQL查待审核的订单数：

SELECT COUNT(*) FROM t_reservation WHERE status = 0;

然后在管理端controller里把这些数值包装成一个DashboardVO对象，页面上用几个简单的卡片展示。这样仅需约一两百行代码，却能同时覆盖数据聚合查询、VO组装、页面模型展示等多个考察点。

5.2 预订资格审核与黑名单机制

人才公寓和酒店还不同，它通常有明确的入住资格限制。可以设计一个简单的“申请人资格标记字段”：用户在注册时填写的“人才类型”或“申请等级”，管理端的预订审核页面会把该字段展示出来，辅助管理员快速判断是否通过审核。更进一步可以加一个黑名单机制：当用户累计两次订单被管理员驳回，或有一次已确认订单却未办理入住（无理由违约），自动将该用户状态置为“审核受限”，限制其发起新的预订申请。

这个机制能体现两个核心技术点：一是状态触发器思想在业务层的落地（数据库触发器属于加分项，但我更推荐在Service层做规则判断，更可控），二是业务规则的持续性影响——一个动作不仅改变当前状态，还影响用户后续行为。这种延伸设计很容易在答辩中给评委留下“业务理解深刻”的印象。

5.3 如果非要引入框架，应该怎么引

如果觉得自己对Servlet的掌握已经足够扎实，考虑快速引入框架提升项目“逼格”，我会给出的优先级是这样的：

• 首选引入HikariCP连接池（现在很多课设还在用最原始的DriverManager，完全可以替换成HikariCP，改造量极小却会让数据库操作可靠性提升明显）。
• 其次引入一个简单的MVC路由框架（比如直接用Spring MVC，但不要引入Spring Boot那一整套。原因是Spring MVC仍然可以配合JSP使用，且路由映射、参数绑定等功能能极大简化Controller层的代码）。
• 最后考虑引入Bootstrap或半成品Admin模板（前端层次的安全改造优先级其实很高，至少可以把项目从“纯学术风格”变成“接近真实系统的UI”，感官分直接拉高）。

需要提醒的是，不推荐在课设一开始就引入这些框架。先完成纯Servlet版本，再考虑扩展，这样你在答辩时才能说清楚每一层到底做了什么，而不是背出来的“框架配置”。

6. 部署上线与答辩演示注意事项

这部分虽然不是代码，但对项目最后的评分影响极大。很多同学本地跑得好好的，一到讲解演示环节就各种翻车，大多出在部署和演示准备上。

6.1 打包部署的完整参考流程

为了让演示时不依赖IDEA内置的Tomcat，建议在答辩前就把项目打包成WAR文件，部署到独立安装的Tomcat中运行。流程大致如下：

1. 在pom.xml中确认打包方式为war（如果用Maven构建），JDK版本和Tomcat版本要匹配，避免出现UnsupportedClassVersionError。
2. 使用Maven执行mvn clean package，在target目录得到war包。
3. 将war包复制到Tomcat的webapps目录，启动Tomcat后自动解压，访问路径就是http://localhost:8080/项目名/（默认不会自动跳到首页的话，可以配置<welcome-file-list>）。
4. 修改数据库连接配置文件时注意环境差异，尤其是数据库地址、用户名和密码。
5. 导入初始SQL脚本，创建数据库和表，必要时插入几条演示账号和房源数据，这个步骤提前在另一台干净机器上演练一遍，确保万无一失。

6.2 演示数据准备与讲解节奏

演示数据的准备非常关键，务必多想一步。不要傻乎乎地把所有数据都建成同一状态，建议提前构造一整套符合业务流程的演示数据：两个角色账号（一个是普通用户，一个是管理员）、至少六条房源记录覆盖不同类型和状态、若干条预订记录覆盖全部状态（待审核、已通过、已驳回、已入住、已退房、已取消各一两条）。

讲解时的演示路径可以这样设计：先用普通用户登录，浏览房源→筛选“一室一厅”→选择一套空闲房源发起预订→进入“我的预订”看到待审核订单→退出登录，切换管理员账号→进入待审核列表→通过刚才的订单→回到普通用户视角看到订单变为“已通过”→办理入住后房间状态变为已入住。这条完整的故事线几乎覆盖了所有核心功能，演示时间也卡得很自然。

一个常见的反面教材：拿到项目后想当然选最新版Tomcat/MySQL，结果Servlet版本、MySQL驱动版本、JSTL版本到处冲突，报错信息让人摸不着头脑。我的建议是：选稳定、常用、网上资料量大的版本。一组我验证过很稳的组合是：Tomcat 8.5或9.0，JDK 1.8/11，MySQL 5.7或8.0，Servlet API 4.0，JSTL 1.2。这个组合的资料足够多，跟所有常见问题都能在搜索引擎里秒查。

7. 最后的经验复盘

一路看下来，无论是技术深度还是业务完整性，这个课题都能稳稳撑住一场答辩。从实际操作感受来说，做“基于Java Servlet的人才公寓客房预订系统”最大的收获不在于“写会了一个页面”，而在于完整经历了“需求分析→数据库设计→分层编码→自测部署”的闭环，而且每一环都没有办法偷懒。

如果让我给正在做类似项目的读者一条最核心的建议，我会说：开发顺序请严格遵循“先做核心流程，再做边缘功能”。先完成“用户注册登录 → 房源列表 → 提交预订 → 管理员审核 → 入退房”这条业务主链路，然后逐步补充公告管理、统计看板、个人中心这些功能。不要一上来就钻研UEditor传图这种炫技小点，也不要在个人中心浪费太多时间，因为核心流程跑通之后，项目就已经具备完整性了。

另一个经验是在写代码的全程都保持注释习惯。课设项目里的代码量并不算大，但类和类之间的调用关系很容易在两周后彻底遗忘。每个核心方法上写清楚“这个方法是干什么的、什么时候被谁调用、需要注意什么”，无论是在后期调试还是写项目报告时，都能大幅节省时间。而且坦白说，答辩老师快速翻阅代码时，注释质量是他们对项目印象的重要组成部分。

最后再分享一个细节：给这个系统做一点“小而美”的设计。比如为登录页放置一张人才公寓的实景图或概念图，在公告栏写一篇欢迎语，在房源详情页标注“含物业费、拎包入住”这类人才公寓特色文案。这些细节不会影响任何功能评分，但会显著提升演示时传递给老师的“完整产品”感觉——这往往比多写一千行增删改查代码更有回报。做一个项目，不是堆功能数量，而是把每一条业务都打磨得经得起追问和推敲，这套方法论在你将来面对更复杂的系统时也一样管用。