JavaWeb宿舍管理系统实战：报修、出入登记与调宿全流程实现

最近我把一个 JavaWeb 数字化高校宿舍报修出入登记调换宿舍管理系统完整跑通了，功能覆盖宿舍报修、出入登记、调换宿舍三个核心场景，技术栈是 JSP + Servlet + MySQL + Tomcat。做之前我以为难点是模块多、页面多，真正做完才发现，宿管员日常最痛的不是界面丑，而是流程断在半路：学生报修了没有派单、访客进楼了查不到记录、调宿审核通过后床位状态和实际情况对不上。这个系统要解决的，正是这些断点。如果你也在准备类似 JavaWeb 项目，或者正卡在“功能都能写，但串不起来”的状态，这篇文章应该能给你一条可以直接照做的实现思路。

1. 宿舍管理员的三件烦心事：报修、出入登记、调宿为什么值得做成系统

1.1 三个场景的真实痛点

先说报修。以前宿舍报修大多靠手写登记本，学生填一句“厕所漏水、灯不亮”，宿管员再抄给维修工，维修工做完之后在本子上打个勾。听起来简单，实际上到处是坑：学生不写房间号，维修工跑错楼；报修单堆在一起分不清谁先报的；维修工做完没销单，宿管员还要打电话追问。这种模式漏的不是一条记录，而是整个可信度。

出入登记的问题更隐蔽。访客进楼要登记姓名、电话、访问对象，但很多人只是随手写一个很难辨认的名字。到了晚上查晚归、查外来人员，只能翻本子，一翻就是几百条。更麻烦的是，学生大件物品搬出楼时如果没登记，出了安全问题没法追溯。纸质记录不是不能用，而是查询、统计、提醒这些动作全部靠人肉完成，效率太低。

调换宿舍则是典型的多表联动问题。一个人从 3 号楼 502 调到 5 号楼 306，宿管要在台账上改学生信息、原宿舍床位状态、新宿舍床位状态，还要标记原宿舍的物品交接情况。只要漏改一张表，就会出现“502 明明没人住却显示有学生”或者“306 已经住两个人却还能分一个床位”。同一个床位被两个人同时操作的情况，在纸质时代几乎无解。

1.2 从纸质登记到数字化的切换点

这台系统的核心价值不是把纸表搬到网页上，而是让数据状态在业务流转过程中保持一致。学生提交报修后，系统记录“待受理”；宿管员派单后，维修工看到“已派单”；维修工更新为“维修中”，最后变成“已完成”。每一步都有时间、操作人、状态变化痕迹，宿管员不用再追着问进度。

出入登记做数字化之后，门卫只需要输入学号或者扫码，系统自动带出姓名、楼栋、房间号，进出方向由操作人选择，所有记录按时间排序，随时可以按楼栋、日期、学生姓名筛选。调宿申请则从学生发起申请开始，宿管员初审、管理员终审、系统释放旧床位并占用新床位，整个链路都在一个事务里完成，避免数据不一致。

所以这个系统的设计主线非常清晰：报修、出入、调宿三个业务场景围绕“状态流转”展开，角色不一样，看到的数据和能做的操作也不一样。

2. 技术选型：JSP/Servlet + MySQL 在这类项目里的边界与价值

2.1 为什么我不一上来就上 Spring Boot

不是 Spring Boot 不好，而是这个场景用 JSP/Servlet 反而更好。宿舍管理系统的并发量很低，演示环境和学校内部使用，几十个人同时操作已经是峰值，Tomcat 加 JSP 完全扛得住。更重要的是，Servlet、Filter、Session、JDBC 事务这些东西是 JavaWeb 基础，手写一遍之后，你对请求是怎么进来、session 是怎么维持、数据库连接是怎么关闭的，会有很直观的感知。

如果直接上 Spring Boot，项目确实很快能跑起来，但学生汇报时经常被问住：启动类里到底做了什么？自动配置怎么生效的？事务注解背后是什么？很多细节被框架封装了，一句“加个注解就行”很难把原理讲透。对于课程设计、毕业设计或者个人学习项目，JSP/Servlet 这套经典组合反而更能体现对 JavaWeb 核心机制的理解。

当然，如果这个系统是给企业正式上线用，我会直接选 Spring Boot + MyBatis-Plus + Vue。但这里的目标是跑通业务且能讲清楚，所以选型上我压住了想上框架的冲动。

2.2 工程结构怎么分层

我按 controller、service、dao、entity 四层来组织。Servlet 只负责接收参数、调用 service、转发或重定向；service 层处理业务规则，比如调宿时要校验目标床位是否空闲；dao 层只写 SQL 和数据访问逻辑；entity 层是数据表对应的 JavaBean。

code复制src/main/java
  com.dorm.entity       Student.java RepairOrder.java EntryExitRecord.java
  com.dorm.dao          StudentDao.java RepairDao.java DormChangeDao.java
  com.dorm.service      DormChangeService.java RepairService.java
  com.dorm.web.base     BaseServlet.java
  com.dorm.web.login    LoginServlet.java
  com.dorm.web.student  StudentServlet.java
  com.dorm.web.dorm     DormServlet.java
  com.dorm.util         DBUtil.java
src/main/webapp
  login.jsp
  static/               css js images
  WEB-INF/jsp/          各角色页面

这样的好处是每个类只干一件事，排查问题的时候不用在 Servlet 里翻几百行 SQL。尤其是调宿这种多步操作，service 层可以专门开事务，dao 层只负责独立的数据操作，事务边界很清楚。

2.3 用户角色与权限模型

我设计了四种角色：学生、宿管员、维修工、系统管理员。权限不用做得很重，用户表里存一个 role 字段，登录后放进 session，再用 Filter 做页面级别的控制，就够用了。

Filter 里只判断“是否登录”，具体到每个 Servlet 方法里再判断角色。这种写法虽然不够工程化，但对于一个单体管理项目来说足够清晰，也不会因为权限框架引入太多复杂度。

3. 数据库设计：三张核心业务表如何撑起完整流程

3.1 宿舍和学生的基本数据，最好一次建对

数据库我建议从基础数据开始建：宿舍楼、房间、床位、学生。这几个表如果设计不好，后面的报修、出入、调宿都会跟着歪。

房间表和床位表示例：

sql复制CREATE TABLE dorm_room (
  id INT PRIMARY KEY AUTO_INCREMENT,
  building_no VARCHAR(20) NOT NULL,
  room_no VARCHAR(20) NOT NULL,
  gender_type TINYINT DEFAULT 1 COMMENT '1男2女',
  bed_count INT DEFAULT 4,
  status TINYINT DEFAULT 1 COMMENT '1正常0停用',
  UNIQUE KEY uk_building_room (building_no, room_no)
);

CREATE TABLE bed (
  id INT PRIMARY KEY AUTO_INCREMENT,
  dorm_room_id INT NOT NULL,
  bed_no VARCHAR(10),
  status TINYINT DEFAULT 0 COMMENT '0空闲1占用2维修/禁用',
  UNIQUE KEY uk_room_bed (dorm_room_id, bed_no)
);

学生表不要只存宿舍楼和房间号，最好把 bed_id 也存进去。因为学生入住和调宿的最小单位是“床位”，只存 room_id 的话，同一间房多个人住，你就不知道谁占哪个床位。实际业务里，宿舍管理员最在意的是“现在哪些床位空着”。

3.2 报修单表：状态字段决定整条流程

报修单表是报修模块的核心，我设计的字段包括业务单号、学生、房间、报修类型、问题描述、照片路径、紧急程度、状态、维修工、创建时间、更新时间。

sql复制CREATE TABLE repair_order (
  id INT PRIMARY KEY AUTO_INCREMENT,
  repair_no VARCHAR(32) NOT NULL UNIQUE,
  student_no VARCHAR(20) NOT NULL,
  dorm_room_id INT NOT NULL,
  repair_type VARCHAR(50),
  description VARCHAR(500),
  image_path VARCHAR(255),
  priority TINYINT DEFAULT 1,
  status TINYINT DEFAULT 1,
  assignee VARCHAR(50),
  create_time DATETIME,
  update_time DATETIME,
  KEY idx_status (status),
  KEY idx_student_no (student_no)
);

status 字段是整个流程的“大脑”。我用数字表示状态：1 待受理，2 已派单，3 维修中，4 已完成待验收，5 已完成，6 已取消。每次状态变更不只是执行一句 update，还要往 repair_log 表里插入一条日志，记录旧状态、新状态、操作人和时间。这个日志在答辩和复盘时非常有用。

我这里故意没有建物理外键，只做逻辑关联。原因是你用 JDBC 操作时，外键约束很容易在调试数据的时候变成阻碍；只要在 service 层保证业务规则，比如报修单里的 student_no 必须真实存在、dorm_room_id 必须属于当前学生，逻辑关联就够了。

3.3 出入登记表：记录谁、何时、进出哪个楼

出入登记表不复杂，关键是把“进”和“出”分开记录，而不是一条记录里同时存 enter_time 和 exit_time。因为门卫一次登记只有一个方向，访客什么时候离开并不由登记时的操作人控制。如果强行做成一条记录，反而会让查询变复杂。

sql复制CREATE TABLE entry_exit_record (
  id INT PRIMARY KEY AUTO_INCREMENT,
  record_no VARCHAR(32) NOT NULL UNIQUE,
  student_no VARCHAR(20),
  visitor_name VARCHAR(50),
  visitor_phone VARCHAR(20),
  visited_student_no VARCHAR(20),
  reason VARCHAR(200),
  direction TINYINT COMMENT '1进0出',
  operator_id INT,
  create_time DATETIME,
  KEY idx_create_time (create_time),
  KEY idx_student_no (student_no)
);

对于本校学生，student_no 必填，visitor 相关字段可以不填。对于访客，visitor 字段必填，同时尽量登记访问对象，方便事后溯源。大件物品搬出的情况，可以在 reason 里写明“搬出电脑主机”之类的说明。

3.4 调宿申请表的原子性设计

调宿申请表的字段围绕“从哪到哪、谁审批、状态到哪一步”来设计：

sql复制CREATE TABLE dorm_change_apply (
  id INT PRIMARY KEY AUTO_INCREMENT,
  apply_no VARCHAR(32) NOT NULL UNIQUE,
  student_no VARCHAR(20) NOT NULL,
  from_room_id INT NOT NULL,
  from_bed_id INT NOT NULL,
  to_room_id INT NOT NULL,
  to_bed_id INT NOT NULL,
  reason VARCHAR(500),
  status TINYINT DEFAULT 1 COMMENT '1待审2初审通过3终审通过4已完成5驳回',
  apply_time DATETIME,
  approve_time DATETIME,
  approve_by VARCHAR(50)
);

调宿最核心的 SQL 不是 update 学生表，而是“查目标床位是否真的空闲”。这个查询要和数据库事务配合，防止两个人同时申请同一个床位。

sql复制SELECT b.id
FROM bed b
JOIN dorm_room r ON b.dorm_room_id = r.id
WHERE r.building_no = ?
  AND r.gender_type = ?
  AND b.status = 0
ORDER BY r.building_no, r.room_no, b.bed_no
LIMIT 1;

如果目标床位已经被占用，哪怕申请审批通过了，最后一步床位变更也会失败。所以我在调宿申请表里直接保存 to_bed_id，而不是等执行时再查，这样可以减少并发下的不确定性。

4. 核心功能按价值排序落地：先跑通登录和通用 Servlet

4.1 BaseServlet 统一分发：少写一半 if else

如果每个功能都写一个 Servlet，项目会有十几个类，并且每个类里都是重复的 doGet / doPost 判断。我写了一个 BaseServlet，用反射根据 action 参数调用方法，子类只需要写业务方法。

java复制public class BaseServlet extends HttpServlet {
    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        req.setCharacterEncoding("UTF-8");
        String action = req.getParameter("action");
        if (action == null || action.trim().isEmpty()) {
            resp.sendError(400);
            return;
        }
        try {
            Method m = this.getClass().getMethod(
                    action, HttpServletRequest.class, HttpServletResponse.class);
            m.invoke(this, req, resp);
        } catch (NoSuchMethodException e) {
            resp.sendError(404, "没有这个操作");
        } catch (Exception e) {
            throw new ServletException(e);
        }
    }
}

比如 StudentServlet 继承 BaseServlet 之后，访问 /studentServlet?action=addRepair 就会自动调用 addRepair 方法。这个方法必须是 public，并且参数列表固定是 HttpServletRequest 和 HttpServletResponse。这种写法省去了大量路由代码，也让功能入口在 URL 上非常直观。

4.2 登录拦截和会话设计

登录用 Session 保存当前用户 id 和 role。所有页面在没有登录时都不能直接访问，我写了一个 AuthFilter 统一拦截。

java复制@WebFilter("/*")
public class AuthFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse resp = (HttpServletResponse) response;
        String uri = req.getRequestURI();
        if (uri.endsWith("/login.jsp")
                || uri.contains("/static/")
                || uri.endsWith("/loginServlet")) {
            chain.doFilter(request, response);
            return;
        }
        Object userId = req.getSession().getAttribute("userId");
        if (userId == null) {
            resp.sendRedirect(req.getContextPath() + "/login.jsp");
            return;
        }
        chain.doFilter(request, response);
    }
}

注意一个容易出问题的点：如果 login.jsp 里引用了 CSS 和 JS，而 Filter 放行了所有请求，静态资源就不会被拦截；但如果你只放行 login.jsp，却忘了放行 /static/，就会出现登录页样式全丢的情况。我实际调试时在这个地方花了不少时间。

4.3 报修流程的代码实现思路

报修流程我把它拆成三个操作：学生提交、宿管派单、维修工更新状态。学生提交比较简单，就是 insert 一条 repair_order，状态默认为 1。宿管派单是 update assignee 字段，并把状态改成 2。维修工更新状态是用一条 join 日志表的事务代码保证“状态变更是可追溯的”。

java复制public boolean updateStatus(int repairId, int fromStatus, int toStatus,
                            String operator) throws SQLException {
    String sql = "UPDATE repair_order SET status=?, update_time=NOW() "
               + "WHERE id=? AND status=?";
    String logSql = "INSERT INTO repair_log(repair_id, from_status, to_status, "
                  + "operator, create_time) VALUES (?,?,?,?,NOW())";
    try (Connection conn = DBUtil.getConnection();
         PreparedStatement ps = conn.prepareStatement(sql);
         PreparedStatement plog = conn.prepareStatement(logSql)) {
        conn.setAutoCommit(false);
        ps.setInt(1, toStatus);
        ps.setInt(2, repairId);
        ps.setInt(3, fromStatus);
        if (ps.executeUpdate() == 0) {
            conn.rollback();
            return false;
        }
        plog.setInt(1, repairId);
        plog.setInt(2, fromStatus);
        plog.setInt(3, toStatus);
        plog.setString(4, operator);
        plog.executeUpdate();
        conn.commit();
        return true;
    }
}

这里最关键的是 WHERE id=? AND status=?，它能防止两个人同时操作同一条报修单导致状态错乱。比如维修工点击完成时，如果这条单已经被取消，update 影响行数为 0，就能及时停止后续逻辑。

4.4 出入登记的“模拟扫码”逻辑

出入登记如果做得很重，比如搞人脸识别、硬件对接，那就超出普通 JavaWeb 项目的范围了。我用的方案是“模拟扫码”：在登记页面放一个输入框，学号或学生卡号输进去后自动带出个人信息。

java复制String studentNo = req.getParameter("studentNo").trim();
Student student = studentDao.findByStudentNo(studentNo);
if (student == null) {
    req.setAttribute("msg", "查无此人，请确认学号");
    req.getRequestDispatcher("/dorm/entry.jsp").forward(req, resp);
    return;
}
String direction = req.getParameter("direction");
EntryExitRecord record = new EntryExitRecord();
record.setStudentNo(student.getStudentNo());
record.setDormRoomId(student.getDormRoomId());
record.setDirection("in".equals(direction) ? 1 : 0);
record.setOperatorId(getLoginUserId(req));
entryExitDao.insert(record);
resp.sendRedirect(req.getContextPath() + "/dorm/entryRecord.jsp");

如果你不了解门卫的实际操作场景，会觉得这个功能没技术含量。但真正常用的其实是“扫码枪就是键盘”的思路：扫码枪本质是一个键盘输入设备，扫一下条码，会自动在输入框里打出学号并模拟回车。所以页面里只要保证输入框 autofocus，再监听回车提交，就能把操作时间从十几秒压到一两秒。这个细节比接任何硬件 SDK 都实用。

4.5 调换宿舍的事务处理

调宿不能只用一条 update 解决，我拆成以下步骤：校验目标床位空闲、占用新床位、释放旧床位、更新学生表的宿舍和床位、更新申请单状态。整个过程必须在一个事务里。

java复制try (Connection conn = DBUtil.getConnection()) {
    conn.setAutoCommit(false);
    // 1. 用 FOR UPDATE 锁住目标床位，防止并发分配
    PreparedStatement psLock = conn.prepareStatement(
        "SELECT id FROM bed WHERE id=? AND status=0 FOR UPDATE");
    psLock.setInt(1, toBedId);
    ResultSet rs = psLock.executeQuery();
    if (!rs.next()) {
        conn.rollback();
        return "目标床位不可用";
    }
    // 2. 释放旧床位
    PreparedStatement psOld = conn.prepareStatement(
        "UPDATE bed SET status=0 WHERE id=?");
    psOld.setInt(1, fromBedId);
    psOld.executeUpdate();
    // 3. 占用新床位
    PreparedStatement psNew = conn.prepareStatement(
        "UPDATE bed SET status=1 WHERE id=?");
    psNew.setInt(1, toBedId);
    psNew.executeUpdate();
    // 4. 更新学生宿舍
    PreparedStatement psStu = conn.prepareStatement(
        "UPDATE student SET dorm_room_id=?, bed_id=? WHERE student_no=?");
    // 5. 更新申请状态
    PreparedStatement psApply = conn.prepareStatement(
        "UPDATE dorm_change_apply SET status=4, approve_time=NOW() WHERE id=?");
    conn.commit();
}

FOR UPDATE 是数据库行级锁，在这个业务里可以防止两个人同时看到床位空闲然后同时申请。它对单体项目来说够用，也不会引入分布式锁这种复杂概念。如果你担心不好讲清楚，可以把它理解为“在数据库层面把目标床位临时锁住，事务提交后再释放”。

5. 部署与排错：IDEA 2023 建 JavaWeb 项目、Tomcat 和 MySQL 8 的实战坑

5.1 用 IDEA 2023 创建 JavaWeb 项目的最简路径

在 IDEA 2023 里创建 JavaWeb 项目，我推荐用 Maven 的 webapp 骨架，而不是手动建目录。新建项目时选 Maven，Archetype 选 maven-archetype-webapp，然后补上 Servlet 和 MySQL 依赖。

xml复制<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>4.0.1</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.33</version>
</dependency>

注意这里的版本对应关系：Tomcat 9 用的是 javax.servlet，Tomcat 10.1 用的是 jakarta.servlet。很多新手项目一上来就用 Tomcat 10，然后代码里全是 javax 包名，启动直接报 NoClassDefFoundError。我的经验是：如果参考代码和课程资料都是旧写法，直接用 Tomcat 9.0，省掉一堆麻烦。

配置运行环境时，IDEA 里新建 Tomcat Server Local，Deployment 里添加 Artifact，选择 war exploded，Application context 写成 /dorm。这样访问路径就是 http://localhost:8080/dorm/。如果你访问 404，先检查 Application context 是不是和预期一致，再检查 Servlet 注解里的 urlPatterns 前面有没有加项目上下文。

5.2 部署到 Tomcat 时最常出错的几个位置

我把实操中常见的报错整理成了一张排查表，照着查能少走很多弯路。

最隐蔽的一个坑是：Maven 项目里如果把 mysql-connector-java 的 scope 写成 provided，IDEA 运行时不报错，但部署到独立 Tomcat 时驱动 jar 没有被打包进去，页面一查数据库就 500。这种问题不是靠看代码能发现的，必须看 Tomcat 的 localhost.log。

5.3 从 500 到页面正常的完整排查链路

我在调试阶段总结了一条顺序链，按这个顺序排错效率最高。先看 IDEA 的 Tomcat 启动日志，有没有端口占用、有没有加载到项目；再看浏览器控制台，404 就查路径，500 就去看 Tomcat 日志的堆栈；接着看数据库连接，SELECT 1 能通不代表 JDBC URL 没问题，时区参数错有可能报的是 The server time zone value 而不是连接失败。

然后处理中文乱码。JSP 页面里 <%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8" %> 必须写上；Servlet 里 req.setCharacterEncoding("UTF-8") 要放在读取参数之前；如果 GET 请求参数也乱码，检查 Tomcat 的 server.xml 里 Connector 是否设置了 URIEncoding="UTF-8"，Tomcat 8 以上默认就是 UTF-8，但有的老项目配置里会把它改掉。

最后是最容易忽略的 session 问题。如果你发现登录成功后跳转又回到登录页，大概率不是 session 失效，而是 Filter 放行路径把登录请求拦截了，导致 session 里根本没有写入用户信息。测试时直接访问一个受保护页面的 URL，看它会不会自动跳到 login.jsp，能很快判断 Filter 是否生效。

6. 如果这个系统要真正上线，我会按什么顺序升级

6.1 先换掉手动 JDBC，再考虑换框架

现在的代码里所有地方都用 DBUtil.getConnection() 手动开连接，功能上没问题，但每次请求都重复建立 TCP 连接，性能一般。真正上线前我第一件事是换成 HikariCP 连接池，配置一个 dataSource，然后从 dataSource.getConnection() 拿连接。这个改动不涉及业务代码，只动 DBUtil 和配置文件，风险很小。

其次是给 SQL 加上命名参数或者干脆用 MyBatis。现在这种 PreparedStatement 写多了之后，字段一多就容易 setString 参数顺序写错。换 MyBatis 不是为了炫技，而是因为 mapper 文件里每个参数都有名字，改 SQL 时不容易把位置搞混。如果你以后要找工作，Spring Boot + MyBatis 是更常见的组合，但底层能读懂这些代码还是需要现在的手写功底。

6.2 补上日志、权限和审计这些看不见的功能

演示系统可以不做日志，但正式用必须做。这里的日志不是 println，而是操作审计日志：谁在什么时间把 5 号楼 201 的报修单状态从 1 改到了 2，谁在什么时候把学号 20230012 的宿舍从 3-502 调到了 5-306。我在 repair_log 和申请单状态字段里已经留了雏形，后续要做的只是把更多操作都纳入同一套日志体系。

权限方面，目前的角色判断散落在各个 Servlet 方法里，如果角色多到十几类，就要引入 RBAC 表了。但宿舍管理场景其实用不到那么重，我的建议是维持角色字段，但把 Filter 里的权限判断抽成一个工具类，比如 hasRole(request, "admin")，这样比到处写 if 清晰得多。

6.3 出入登记从“模拟扫码”到二维码的演进

模拟扫码在演示环境够了，实际宿舍楼里可以做成更轻量的二维码方案。给每栋楼、每个房间生成一个二维码，学生进楼时用自己的校园系统账号登录手机页面，扫房间码后选择“进入”或“离开”，后台记录学号和房间号。这个方案不用买硬件，也不需要改现有 JavaWeb 结构，只需加一个生成二维码的工具库，比如 ZXing，再加一个移动端适配的登记页面。

真正生成二维码时，不要把整个 URL 写死成管理员登录后看到的路径，要保证普通学生扫完码自动进入登记模式而不是全功能后台。这里会涉及一个比较容易被忽视的点：二维码里的参数如果包含 roomId，生成时要用防伪参数，否则别人改一下 roomId 就能替别人登记。演示项目可以忽略，正式用的时候至少要给二维码加一个不透明的内部编号。

6.4 最后说一个实际取舍心得

做这个系统给我最大的教训是，业务单号千万不要只用自增主键。报修单、出入登记、调宿单都要和线下纸质台账对账，自增主键既不好看，也容易在数据导入导出时重号。我后来在 Java 里统一生成 yyyyMMddHHmmss + 四位随机数 作为单号，所有模块共用一套规则。这个改动很不起眼，但它决定了系统能不能和线下管理真正对上。建议你开工前先把单号规则定好，否则后面改起来会牵连很多表。