企业官网建设流程全解析

1. 先说清楚：这个JSP+Servlet的会议室管理系统到底是个什么项目

如果你正在做JavaWeb的课程设计或者毕业设计，那你对这个标题应该不陌生。JSP + Servlet + MySQL这组技术栈听起来像是十年前的东西，但实际上直到现在，大量院校的JavaWeb课程依然以它为教学核心——因为它是理解HTTP请求处理、Servlet生命周期、会话管理和JDBC数据库访问的最佳入门组合。很多学生的期末作业就是"基于JavaWeb的XX管理系统"，会议室管理系统就是其中经典的题目之一。

这个项目的本质，是围绕"企业会议室资源"做一套完整的预约与调度系统。核心场景很直白：公司有很多间会议室，员工要开会时需要提前预约某个时间段，管理员需要审核或管理这些预约，避免会议室时间冲突。整个系统涉及用户登录、角色区分、会议室信息维护、预约申请、审批流程这几个基本模块，刚好把JavaWeb必考的知识点全部覆盖了。

我在帮很多学弟学妹调这个项目时发现，大家的问题往往不在"代码写不出来"，而在几个更底层的地方：环境怎么配、表结构怎么设计才合理、预约的时间冲突到底怎么判断、为什么自己电脑上跑得好好的换台机器就404了。这篇文章我就按自己实际做这个项目的顺序来整理，从技术选型的思考、数据库设计、项目骨架搭建，到核心功能的实现思路和最常见的坑，全部过一遍。如果你是第一次接触这个技术栈，按这个流程走一遍，基本能把整个项目从零到一跑通。

2. 为什么选JSP+Servlet而不是Spring Boot：先理解这套技术栈的定位

我看到不少人会问：都什么年代了，为什么不用Spring Boot？这个问题其实得看场景。

2.1 课程设计场景下的技术选型逻辑

学校布置这个题目时，考察的核心是"你是否理解JavaWeb最底层的运作机制"。Spring Boot高度封装，一个注解搞定路由、自动配置了内嵌Tomcat，你根本看不到请求是怎么进到Servlet、怎么通过web.xml映射的。而JSP+Servlet把整个过程暴露得很彻底：浏览器发起请求，Tomcat根据web.xml找到对应的Servlet，Servlet处理业务逻辑并调用JDBC操作MySQL，最后把结果转发给JSP渲染页面。每一环都看得见摸得着。

2.2 JSP+Servlet适合解决什么类型的问题

换句话说，这套技术栈最适合的就是"表单提交 + 数据展示 + 增删改查"这类管理型系统。会议室管理系统恰好命中：登录表单、预约表单、会议室列表展示、预约状态更新。用原生Servlet接收参数、用JDBC操作数据库，代码量会比Spring Boot多不少，但每行代码都在告诉你"底层在做什么"，这对后续学习SSM或Spring Boot反而有帮助——你会发现那些框架做的事情，本质就是把这些重复劳动封装起来。

2.3 实现这个项目的技术要点全景

落到具体技术上，这个项目需要掌握的事情大概是下面这张表：

如果把这些点都掌握了，你不仅能做会议室管理系统，换个题目——实验室管理系统、图书馆座位预约系统——思路完全一致，改改表字段和页面文案就又是一个新项目。

3. 先设计数据库再写代码：会议室系统的核心表结构

我在实际操作中见过太多"上来就写代码，写到一半发现字段不够用"的情况。做这类系统，数据库设计必须前置，因为后续所有Servlet业务逻辑都是围绕数据表展开的。

3.1 三张核心表：用户表、会议室表、预约表

会议室管理系统的业务逻辑不算复杂，三张表就能支撑起来。第一张是用户表，用来存账号密码和角色。管理员和普通员工可以放在同一张表里，用role字段区分，这样登录逻辑只需要写一份。字段至少要有id、username、password、role、real_name，如果需要做用户信息展示页，可以再加email、department、phone这些基本信息。

第二张是会议室表，存每间会议室的基本属性。我在设计时常用这些字段：id、room_name、capacity（容纳人数）、location（楼层位置）、facilities（设施描述，如投影仪、电视、视频会议系统）、status（是否停用）。这里有个容易被忽视的细节：status字段不要和"是否被预约"混在一起。会议室本身是长期存在的资源，而某个时间段的占用情况应该由预约表来体现，会议室表的status只表示"这间会议室是否可被使用"。

第三张是预约表，这也是整个系统最核心、最容易出错的地方。字段包括：id、user_id（预约人）、room_id（预约的会议室）、book_date（使用日期）、start_time（开始时间）、end_time（结束时间）、purpose（会议主题）、status（预约状态：待审批/已通过/已拒绝）、create_time。status字段驱动了整个审批流程：用户提交预约时默认为"待审批"，管理员把status改为"已通过"后，这个时间段就被锁定了。

3.2 时间冲突的判断逻辑与SQL写法

预约模块最关键的算法是"同一间会议室在同一时间段不能被重复预约"。判断冲突的SQL可以这样理解：现有预约A的时间范围是[start1, end1]，新预约B的时间范围是[start2, end2]，两者冲突的条件是"A的开始时间早于B的结束时间，并且A的结束时间晚于B的开始时间"。

用SQL表达就是：

SELECT COUNT(*) FROM booking WHERE room_id = ? AND book_date = ? AND status = 'APPROVED' AND start_time < ? -- 新预约的结束时间 AND end_time > ? -- 新预约的开始时间

这段话值得细看：如果查出来COUNT大于0，说明这个时间段已经被占用。日期相等也要带上，因为跨天的预约通常不允许（业务上可以约定只能当天预约，避免跨天逻辑变得复杂）。写这套参数的时候要注意，?的顺序不能错，我习惯按"room_id、book_date、新结束时间、新开始时间"的顺序赋值，这样心理负担最小。

3.3 建表SQL示例与设计建议

我给一个可以直接用的建表SQL，你可以根据自己的业务微调：

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(30) UNIQUE NOT NULL, password VARCHAR(64) NOT NULL, role VARCHAR(10) DEFAULT 'USER', real_name VARCHAR(30), department VARCHAR(50), phone VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_room ( id INT PRIMARY KEY AUTO_INCREMENT, room_name VARCHAR(50) NOT NULL, capacity INT DEFAULT 10, location VARCHAR(100), facilities VARCHAR(200), status VARCHAR(10) DEFAULT 'ENABLE' ); CREATE TABLE t_booking ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, room_id INT NOT NULL, book_date DATE NOT NULL, start_time TIME NOT NULL, end_time TIME NOT NULL, purpose VARCHAR(200), status VARCHAR(10) DEFAULT 'PENDING', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_booking_user FOREIGN KEY (user_id) REFERENCES t_user(id), CONSTRAINT fk_booking_room FOREIGN KEY (room_id) REFERENCES t_room(id) );

这里有个实际经验：外键建议加上，因为预约表里的user_id和room_id必须真实存在。有些人为了图省事不加外键，结果删掉一个会议室之后，历史预约记录就变成了悬空的脏数据。但要注意，加了外键之后，删除会议室时会因为外键约束失败——这时候正确的做法是不做物理删除，而是把t_room表里的status置为"DISABLE"，也就是逻辑删除。这是个很多教程里不会说的设计细节。

4. 项目骨架搭建：从IDEA里的空工程到能跑起来的Web应用

数据库设计完毕，接下来该搭工程了。这步对新手来说最劝退，因为涉及的概念比较多。我详细拆开讲。

4.1 版本选择：JDK、Tomcat、MySQL的搭配

先说版本，这是我踩过最大的坑之一。JavaWeb的教程水平参差不齐，网上很多资料用的是老版本，直接照抄容易在依赖和API上报错。

比较稳的组合是这种：JDK 1.8（绝大多数教学环境默认版本）、Tomcat 8.5或9.0、MySQL 8.0.xx、IDEA 2020以上版本。注意一个关键点：Tomcat 10及以上版本把javax.servlet包迁移到了jakarta.servlet，老教程里的import javax.servlet.http.HttpServlet在Tomcat 10上会直接编译报错。如果你用的是Tomcat 9，继续用javax没问题；如果你下载了最新的Tomcat 10+，就要把导入语句全部改成jakarta.servlet。很多同学项目起不来，十有八九是这里出了问题。

MySQL 8.0和旧版5.7也有区别，最明显的是JDBC驱动类名变了。MySQL 5.x时代用com.mysql.jdbc.Driver，MySQL 8.x必须换成com.mysql.cj.jdbc.Driver，否则启动时会提示找不到驱动类。

4.2 IDEA中创建Web工程的完整步骤

在IDEA中，有两种常见的工程形态：一种是"Java Enterprise"方式新建的Web应用，自动生成WEB-INF目录和web.xml；另一种是普通的Java工程手动添加Web支持。新手我更推荐前者，直接用IDEA新建项目时选择Java Enterprise，勾选Web Application模板，再确认Tomcat已经配置好。如果IDEA版本没有Java Enterprise选项，可以在普通的Java工程上右键添加框架支持，选择Web Application，效果是一样的。

创建完成后，你的工程目录应该是这样分层：

src/main/java （Java源码：servlet、dao、entity、filter等） src/main/webapp （Web根目录） ├── WEB-INF/web.xml ├── css/ js/ ├── login.jsp ├── room_list.jsp └── booking_manage.jsp

这里要提醒一点：很多新手会把JSP文件直接丢到WEB-INF目录里，导致浏览器访问不到。WEB-INF下放的是class文件、lib包和配置，JSP作为静态视图文件应该放在webapp根目录或它的子目录中。

4.3 引入依赖：MySQL驱动和JSTL

在这个纯Servlet项目中，要用到两个外部库：MySQL JDBC驱动mysql-connector-java和JSTL标签库jstl-1.2.jar。前者在连接数据库时必需，后者用于JSP页面中循环遍历列表数据（否则你得在JSP里写一堆Java代码，页面会变得非常难看）。

在IDEA中引入jar包的方式是：把jar包放到WEB-INF/lib目录下，然后右键选择Add as Library。需要特别强调，项目发布到Tomcat运行后，Tomcat加载的是这个lib目录下的jar包，而不是IDEA的Library缓存。所以如果你发现代码编译通过但运行时提示ClassNotFoundException，先检查jar包是否真的在WEB-INF/lib里。

4.4 web.xml配置详解

传统Servlet项目必须在web.xml中声明Servlet的映射关系。现在的注解方式（@WebServlet）也可以，但课程设计中通常要求写web.xml，这也更能体现对底层的理解。核心配置长这样：

<servlet> <servlet-name>LoginServlet</servlet-name> <servlet-class>com.meeting.servlet.LoginServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>LoginServlet</servlet-name> <url-pattern>/login</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>login.jsp</welcome-file> </welcome-file-list>

这一段的信息量挺大的：url-pattern是浏览器地址栏访问的路径，/login意味着表单的action指向login这个地址时，请求会被LoginServlet接收。welcome-file-list配置了访问根路径时默认打开的页面，一般指向登录页。

4.5 配置Tomcat运行环境

在IDEA的运行配置（Run/Debug Configurations）里选择Tomcat Server -> Local，在Deployment页签添加当前工程的Artifact。注意右下角有一个"Application context"，它决定了访问路径前缀，建议保持根路径/，这样访问地址就是http://localhost:8080/而不是http://localhost:8080/xxx_war_exploded/。每次修改Java代码后点击Redeploy或直接重启Tomcat，修改JSP后则不需要重启，刷新页面就能看到效果。

5. 核心功能实现拆解：一个预约请求从浏览器到MySQL的完整旅程

现在进入代码编写阶段。这一节我以"会议室列表展示"和"提交预约"两个核心场景为例，把整个请求链路串起来。

5.1 先搭一个JDBC工具类，省掉每次连接的重复代码

写DAO之前，先封装一个JDBC工具类，把加载驱动、获取连接、关闭资源的逻辑统一放进去。这里直接上我实际使用的版本：

public class JdbcUtil { private static final String URL = "jdbc:mysql://localhost:3306/meeting_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai"; private static final String USER = "root"; private static final String PASSWORD = "123456"; static { try { Class.forName("com.mysql.cj.jdbc.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) { try { if (rs != null) rs.close(); } catch (SQLException e) { e.printStackTrace(); } try { if (ps != null) ps.close(); } catch (SQLException e) { e.printStackTrace(); } try { if (conn != null) conn.close(); } catch (SQLException e) { e.printStackTrace(); } } }

这里面有两点值得注意。第一，URL里必须带characterEncoding=utf8和serverTimezone=Asia/Shanghai，前者解决中文乱码，后者解决MySQL 8.0的时区报错。第二，close方法的顺序必须是先关闭ResultSet再PreparedStatement再Connection，写反了会报资源泄漏。

5.2 用户登录与会话管理

登录逻辑看起来简单，但要把"会话"概念放进去。LoginServlet的doPost方法要做这几件事：读取表单提交的username和password，调用UserDao的findByUsernameAndPassword方法，如果查到了用户，就把用户对象放进session：

HttpSession session = request.getSession(); session.setAttribute("loginUser", user); response.sendRedirect("roomList");

这里我用的是重定向而不是转发。区别在于：重定向会使浏览器地址栏变成roomList，用户刷新页面不会重复提交登录表单；而转发的话，地址栏还是login，刷新会再次提交表单。这个细节在写教务系统类项目时很重要，建议养成"增删改后重定向，查询展示用转发"的习惯。

为了防止未登录用户直接通过在地址栏输入URL来访问会议室列表或预约页面，需要一个Filter统一拦截。Filter的核心逻辑是检查session里是否存在loginUser，不存在则跳回登录页：

public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); if (uri.endsWith("/login") || uri.endsWith("login.jsp")) { chain.doFilter(req, resp); return; } if (request.getSession().getAttribute("loginUser") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(req, resp); } }

这个Filter在web.xml里配置时，url-pattern写成/*，作用范围覆盖全站，但在判断中放过登录相关页面和静态资源。如果你用了CSS、JS、图片，记得也要在Filter中放行，否则页面会变得丑到崩溃。

5.3 会议室列表分页展示：DAO查询 + JSP渲染

查询会议室列表是典型的读操作。RoomDao里写一个listByPage方法：

public List<Room> findByPage(int pageNo, int pageSize) { String sql = "SELECT * FROM t_room WHERE status='ENABLE' LIMIT ?, ?"; // 参数：pageNo为0时返回第一页 }

对应RoomListServlet，逻辑是接收page参数（默认1），查询总数和当前页数据，把列表和分页信息放进request作用域，然后转发给roomList.jsp：

request.setAttribute("roomList", rooms); request.setAttribute("totalPages", totalPages); request.getRequestDispatcher("room_list.jsp").forward(request, response);

JSP页面的核心渲染靠JSTL的c:forEach循环，本质是HTML中嵌入标签来遍历Java集合。这也是我强调要引入jstl-1.2.jar的原因——如果不引入，你只能在JSP里写<% for(Room r : list) { %>这种scriptlet，代码非常不整洁：

<c:forEach items="${roomList}" var="room"> <tr> <td>${room.roomName}</td> <td>${room.capacity}人</td> <td>${room.location}</td> <td><a href="bookingForm?roomId=${room.id}">预约</a></td> </tr> </c:forEach>

5.4 表单提交预约与冲突校验的完整代码

这是整个系统最核心的部分。用户在会议室列表点击"预约"，跳转到预约表单页，填入日期、开始时间、结束时间、会议主题，然后提交到BookingServlet。这时doPost方法要做三步处理。第一步把表单参数收集到Booking对象里。第二步做时间冲突校验，调用BookingDao的checkConflict方法，如果返回值大于0，说明该会议室在这个时间段已被占用，需要跳回到预约页面带上提示信息。第三步，无冲突才执行插入，status默认设为PENDING。

写冲突校验时有个坑，用户提交的时间是String类型，比如"09:00"和"10:30"，传递给PreparedStatement时注意类型映射。如果表字段是TIME类型，可以直接setString传，MySQL会帮你转换。但如果表字段是DATETIME或者你想把日期和时间合并比较，就要用java.sql.Timestamp.valueOf进行转换。

5.5 管理员审核预约的权限控制

管理员登录后看到的不是普通的预约表单，而是一个待审批列表。这个页面要根据当前登录用户的角色来渲染。实现方式是：在JSP页面开头判断session中的用户角色，用JSTL的c:if标签做条件切换：

<c:if test="${loginUser.role == 'ADMIN'}"> <a href="bookingApprove">进入审批后台</a> </c:if>

审批操作本身很简单，就是管理员审核通过时执行"UPDATE t_booking SET status='APPROVED' WHERE id=?"，拒绝时执行"UPDATE t_booking SET status='REJECTED' WHERE id=?"。真正要注意的是系统必须防止普通用户直接通过地址栏访问审批Servlet——所以上一节写的LoginFilter要做加强，不仅判断是否登录，还要判断角色权限。具体做法是扩展Filter，检查URL以approve开头时，session中的用户必须是ADMIN。

这里我想多说一句。很多人的项目能做到"功能都有"，但权限校验却做得稀松：普通用户只要能猜到管理端URL就能进后台改数据。这在实际答辩中是个明显的减分项。你要做的只是Filter里多写一个角色判断，这一点点的严谨度会让整个项目质量上一个台阶。

6. 环境与部署层的"老坑"：整理我帮人调试时遇到的最常见问题

我把这些年帮人调这个项目遇到的报错和诡异现象做了个归类。这些问题是搜索引擎里反复出现的，基本覆盖了JSP+Servlet+MySQL环境下的绝大多数故障场景。

6.1 Java文件修改后不生效

IDEA里修改了Java类，刷新浏览器后却还是旧逻辑。原因通常是Tomcat没有重新编译部署。有人以为运行按钮重启了就万事大吉，但在调试模式下点"Update resources"只能更新静态资源，修改了Java代码必须点"Update classes and resources"或"Redeploy"。如果你改了web.xml、Filter或Servlet映射，建议直接Redebug或重启Tomcat，这样最保险。

6.2 英文正常但中文全是乱码

乱码问题在JavaWeb项目中是个经典综合症，要从四个层面排查。第一层是数据库层面，建库时要指定utf8mb4编码。第二层是连接层面，JDBC URL带上characterEncoding=utf8。第三层是请求层面，在web.xml里配置CharacterEncodingFilter（或自己在Filter中强制request.setCharacterEncoding("utf-8")和response.setContentType("text/html; charset=utf-8")）。第四层是页面层面，JSP文件头部要有<%@ page contentType="text/html;charset=UTF-8" language="java" %>。

这四层缺一个都可能乱码，而且最诡异的是有时候只在某个特定页面乱码，其他页面正常——这种通常就是那个页面漏了page指令。

6.3 MySQL 8.0安装和连接时报错

聊天区和知乎上被问爆的几个MySQL问题我都遇到过。第一个是安装时卡在最后一步（Apply Configuration），多半是之前的旧版本没卸干净或服务被占用，建议安装时选自定义，并且记得把服务勾成手动启动。第二个是连接报Public Key Retrieval is not allowed，在JDBC URL后面加allowPublicKeyRetrieval=true&useSSL=false可解。第三个是时区问题，报错信息里会出现The server time zone value 'Öйú±ê׼ʱ¼ä'这种乱码，URL加上serverTimezone=Asia/Shanghai即可。

6.4 404和500各自意味着什么

这两个状态码是日常交流中高频出现的话题。404表示请求的URL没有对应的Servlet或页面，先检查web.xml的url-pattern路径和form表单的action是否一致，再检查你有没有在地址栏输入完整路径时漏掉了上下文路径。500表示服务器代码抛出异常，去看IDEA控制台的错误堆栈，最常见的错误依次是空指针（对象没有从DAO查出来）、SQL语法错误（表名或字段名写错）、驱动类找不到（jar包没有放到WEB-INF/lib）。

6.5 数据库连接耗尽或卡死

操作数据库之后忘记关闭连接，时间一长就会报连接池超时。这是个非常隐蔽的性能问题，因为单次跑不会出错，但多操作几次就卡死。我见到很多新手只关了PreparedStatement而忘了关Connection，或者try-with-resources用得不对。用上面封装的JdbcUtil.close方法统一关闭就是一种保险的做法。

7. 以我的实操经验做一个收尾

这个项目做下来，整条链路——环境配置、表结构设计、Servlet路由、JSP渲染、Filter拦截、JDBC操作——就像把JavaWeb的骨架完整摸了一遍。个人体会最深的是：这类管理系统写起来没有太多"算法难度"，真正决定项目质量的是细节，比如时间冲突校验的SQL边界条件、权限控制是否严谨、数据库字段设计是否留足扩展空间。

最后分享一个小技巧，算是我调试这类项目的固定套路：如果你怀疑某个环节出了问题但不知道从何查起，先在各个Servlet的doGet/doPost入口加一条打印语句，确认请求是否到达了对应代码。输出到控制台，几个关键字就能判断出是请求没进来、数据库查不出数据，还是JSP渲染出了问题。这种做法俗是俗了点，但在没有高级调试工具加持的JSP项目里，它往往能让你在五分钟内定位问题，比盲改代码高效得多。