企业官网建设流程全解析

作为一个带过不少学生做 Java Web 课设、也亲手维护过几个老 JSP 项目的人，我看到“1.JSP课表查询系统”这个标题时，第一反应是亲切。这几乎是每个学 Java 的人都会遇到的一个经典练手项目，也是很多高校信息管理系统里真实存在的一个模块。它看起来简单，无非就是“查课表”三个字，但真正动手做的时候，你会碰到数据库设计、会话管理、中文乱码、路径跳转、部署上线等一系列问题，把这些点全部理顺了，你对整个 Java Web 开发的理解会上一个台阶。

这篇文章，我就以这个项目为线索，从整体设计思路、数据库建模、核心功能实现，到部署排查，完整地把这个系统拆开揉碎讲一遍。不管你是刚学完 Servlet 和 JSP 的学生，还是突然接到一个老项目需要维护的开发者，这篇文章都能给你一条比较清晰的路线，帮你少走一些我当年走过的弯路。

1. 项目整体设计与技术选型拆解

1.1 为什么这个项目适合用 JSP 来做

先聊一个很多人会纠结的问题：都什么年代了，还有必要用 JSP 吗？

课表查询系统这个项目，本质上是典型的“数据展示型”应用——数据库里存课程安排，用户通过浏览器查询并看到结构化的表格结果。它有几个特点：逻辑不复杂、页面交互要求不高、核心是数据的读取和展示。这类场景恰恰是 JSP 的舒适区。

JSP 允许你在 HTML 中直接嵌入 Java 代码，通过 JSTL 标签和 EL 表达式可以非常直观地把后台数据渲染到页面上。和纯 Servlet 输出 HTML 相比，JSP 的代码可读性要高得多；和前后端分离的 SPA 相比，JSP 又不需要处理跨域、接口鉴权、前端构建那一整套复杂流程。对于一个教学性质或者内部使用的系统来说，JSP 的开发效率和维护成本都非常有优势。

当然，选择 JSP 也意味着你要接受一个现实：前端页面和 Java 代码会以比较“暧昧”的方式共存在同一个文件里。这就对你提出了一个要求——必须在代码结构上做足够清晰的划分，否则项目一旦变大，JSP 页面会迅速腐化成一个谁也不敢动的“屎山”。

1.2 三层架构在课表系统中的具体落地

既然选择了 JSP，架构上就不能太随意。我见过很多课设项目，所有 JDBC 代码直接写在 JSP 页面里，数据库连接散落各处，改一个字段要翻遍几十个文件。这种写法在小项目里勉强能跑，但完全谈不上可维护性。

我比较推荐的做法是三层架构：

• 表现层（JSP 页面 + Servlet）：负责接收请求、调用业务逻辑、跳转或渲染页面。这里不写任何 SQL。
• 业务层（Service）：负责具体的业务判断，比如判断当前用户是学生还是教师、根据身份返回不同的课表数据。这里不写任何 JDBC。
• 持久层（DAO）：负责和数据库交互，写 SQL、执行查询、封装结果集。这里不写任何业务判断。

三层之间通过对象传递数据，比如用一个Course对象来表示一条课程记录，用一个User对象来表示登录用户。

这个分层在你写课表查询系统的时候看起来可能有点“杀鸡用牛刀”，但它的价值在后期的维护和扩展上。比如用户提出“我要增加一个导出课表为 Excel 的功能”，你只需要在表现层加一个 Servlet，在 Service 层加一个方法，底层 DAO 完全不用动。这种松耦合带来的从容感，是你把代码全部堆在一个 JSP 文件里永远体会不到的。

1.3 功能模块划分：别一上来就写代码

动手敲代码之前，先把功能模块理清楚。一个完整的课表查询系统通常包含以下几个模块：

• 用户登录与注册：区分学生、教师、管理员三种角色。
• 课表查询：学生按班级查课表，教师按姓名查课表。
• 课表管理（管理员）：课程信息的增删改查，维护班级、教师、教室等基础数据。
• 个人中心：修改密码、查看个人信息。

别小看这个划分。我见过不少同学拿到题目就开始写login.jsp，结果写到一半发现课表页面还需要班级信息、需要判断今天是第几周、需要区分单双周课程，然后开始疯狂往已有的代码里塞补丁，最后整个项目逻辑拧成一团。先把模块画出来，标清楚每个模块的输入是什么、输出是什么、依赖哪些数据表，再动手写代码，整体效率会高很多。

2. 数据库设计与核心模块拆解

2.1 数据表设计：这是整个系统的地基

课表查询系统的核心在数据库。我建议你先把表结构设计好，并且用几组真实的教学数据去验证设计是否合理，再开始写代码。这比你代码写到一半回来改表结构要省事得多。

一个实践中比较简洁有效的表结构设计如下：

用户表（user）

课程表（course）

班级表（class）

这三张表的关联关系是：课程表中teacher_id关联用户表的教师用户，class_id关联班级表。一个教师可以上多门课，一个班级会有多门课，所以课程表的这两列天然就是多对多关系的中间载体。这样的设计足够支撑学生查自己班的课表、教师查自己教的课，也方便管理员维护课程。

这里有一个细节值得展开说一下：week_type这个字段。大学课表里单双周课程非常常见，第 1-16 周单周上课、第 2-16 周双周上课，这是很普遍的教学安排。如果不设计这个字段，你只能在查询结果里把所有周都展示出来，然后有课没课全靠用户自己判断，体验很差。加上这个字段后，查询时只需要判断“当前周”是单数还是双数，再和week_type比对即可，代码逻辑非常清晰。

2.2 主查询 SQL 的编写：从需求倒推语句

数据表设计好之后，核心的查询 SQL 其实已经呼之欲出了。

学生查看课表的需求是：输入班级 ID（这个 ID 通常从登录用户的class_id字段获取），查询该班在指定周的所有课程安排。

对应的 SQL 大意如下：

SELECT course_name, teacher_id, classroom, day_of_week, start_section, end_section FROM course WHERE class_id = ? AND ? BETWEEN week_start AND week_end AND ( week_type = 'all' OR (week_type = 'odd' AND ? % 2 = 1) OR (week_type = 'even' AND ? % 2 = 0) ) ORDER BY day_of_week, start_section;

这条 SQL 里我用了三个?占位符，分别表示班级 ID、当前周数、当前周数。第三个?在判定奇偶时又用了一次，所以需要传两次。这里我特别说明一下，为什么周数要用参数传进去，而不是在 SQL 里直接写WEEK()函数？因为课表的周数和自然日历的周数并不总是一致，学校的教学周通常有自己的定义（比如从开学第一天算起为第一周），这个数据最好由后端 Java 代码计算后传参，而不是让数据库去猜。

你可能已经注意到了，这条 SQL 是直接在course表上查，并没有 JOIN 班级表。这是刻意为之的简洁设计——课表查询系统的核心操作本来就是单一数据表上的条件查询，强制 JOIN 反而会让 SQL 变得不必要的复杂。真正需要 JOIN 的场景出现在教师查课表的时候。

教师查课表的需求是：输入教师姓名或工号，查询该教师所有任课的安排。由于课程表里存的是teacher_id，而用户信息在user表里，这时候就必须要 JOIN：

SELECT c.course_name, cl.class_name, c.classroom, c.day_of_week, c.start_section, c.end_section FROM course c INNER JOIN user u ON c.teacher_id = u.id INNER JOIN class cl ON c.class_id = cl.id WHERE u.role = 'teacher' AND u.username = ?

这里有个需要留意的细节：查询条件是u.username（工号），而不是u.name（姓名）。工号是唯一的，姓名可能重复。用姓名查询会造成歧义，所以虽然需求里说“按姓名查”，实现时仍然建议以工号作为检索条件。

2.3 为什么要用 PreparedStatement 而不是拼接字符串

一个很多新手会踩的坑：直接把用户输入拼进 SQL 字符串里。

// 错误示范 String sql = "SELECT * FROM user WHERE username = '" + username + "' AND password = '" + password + "'";

这种做法极其危险。只要用户在用户名输入框里填一个' OR '1'='1，你的登录认证就被绕过了。在课表查询系统里，这不仅是数据泄露的问题，更是整个系统权限体系的崩溃。

正确做法是使用PreparedStatement：

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

PreparedStatement会先把 SQL 结构发送给数据库做预编译，用户输入的值只作为参数传递，不会被当作 SQL 代码执行。这就从源头上杜绝了注入问题。还有一个附带的好处：预编译后的语句在重复执行时性能更优，因为数据库不需要每次都重新解析 SQL 语法。

密码存储这块我额外多说一句。用明文存密码也是个非常常见的错误。一旦数据库泄露，所有账号一览无余。正确做法是使用SHA-256加盐哈希，或者使用BCrypt这样专门为密码设计的慢哈希算法。虽然课表查询系统的数据敏感性不算高，但养成这个安全习惯，对你未来的任何一个项目都有好处。

3. 从零到一的实践过程

3.1 开发环境与项目骨架搭建

环境配置这部分，我直接给你一套可以直接抄的组合：

• JDK：1.8 或 11（太新的版本和 Tomcat 的兼容性需要额外注意）
• Web 容器：Tomcat 8.5 或 9.0（Tomcat 10 及之后版本 Jakarta EE 命名空间变化较大，如果跟着老教程写代码会踩坑，不建议新手用）
• 数据库：MySQL 5.7 或 8.0（两个大版本的驱动类名略有差异，8.0 用的是com.mysql.cj.jdbc.Driver）
• IDE：推荐 IntelliJ IDEA，如果你是在学校机房里做课设，Eclipse 也可以用
• 构建工具：Maven，用来管理依赖要比手动拖 jar 包舒服得多

在 Maven 的pom.xml中，你需要添加这些核心依赖：

<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency>

这里注意三点：servlet-api的 scope 必须设为provided，因为 Tomcat 自带这个库，如果打包进 WAR 反而可能冲突；JSTL 依赖不可或缺，没有它 JSP 里的<c:forEach>标签就不可用；MySQL 驱动的版本号要和你本地的数据库版本匹配。

项目结构我建议这样组织：

src/main/java ├── com.example.pojo // 实体类：User, Course, Class ├── com.example.dao // 数据访问层：UserDao, CourseDao ├── com.example.service // 业务层：CourseService, UserService ├── com.example.servlet // Servlet：LoginServlet, CourseQueryServlet └── com.example.util // 工具类：DBUtil, PasswordUtil src/main/webapp ├── login.jsp ├── student_course.jsp ├── teacher_course.jsp └── WEB-INF/web.xml

这是一个很标准的 Java Web 项目骨架。把代码放对位置，比代码本身写得漂亮更重要。

3.2 用户登录与会话管理实战

登录逻辑是整个系统的入口，也是权限控制的中枢。一个合格的登录功能包含以下步骤：接收表单参数、校验非空、查询数据库、比对密码、写入会话、重定向到对应角色的首页。

我先说一下这里一个非常重要的设计决策——登录成功后的跳转，必须使用重定向而不是请求转发。

原因很简单：如果使用请求转发，浏览器的地址栏停留在login.jsp上，用户刷新页面时，表单数据会被重新提交一遍，导致重复登录，严重的会造成会话数据错乱。而重定向会告诉浏览器“去访问一个新的地址”，刷新时只会重复请求新地址，不会再触发登录逻辑。

登录 Servlet 的核心代码大致如下：

@WebServlet("/login") public class LoginServlet extends HttpServlet { private UserService userService = new UserService(); @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String username = req.getParameter("username"); String password = req.getParameter("password"); User user = userService.login(username, password); if (user == null) { req.setAttribute("error", "用户名或密码错误"); req.getRequestDispatcher("/login.jsp").forward(req, resp); return; } HttpSession session = req.getSession(); session.setAttribute("currentUser", user); session.setMaxInactiveInterval(30 * 60); if ("student".equals(user.getRole())) { resp.sendRedirect(req.getContextPath() + "/student/course"); } else if ("teacher".equals(user.getRole())) { resp.sendRedirect(req.getContextPath() + "/teacher/course"); } else { resp.sendRedirect(req.getContextPath() + "/admin/dashboard"); } } }

这个代码里有几个细节值得认真体会。

第一，session.setAttribute("currentUser", user)把用户对象直接放进了会话。之后任何 JSP 页面都可以通过${sessionScope.currentUser.name}获取当前登录用户的姓名，非常方便。

第二，session.setMaxInactiveInterval(30 * 60)设置了会话超时时间为 30 分钟。这样一来，用户长时间不操作后会自动退出登录，避免一个公共电脑被后来的人冒用身份。

第三，请求转发和重定向在这里同时出现了，而且各自在恰当的时机被使用。登录失败时用转发，因为需要把error属性传给 JSP 页面显示；登录成功时用重定向，因为需要浏览器跳转到全新的地址。

页面上的权限控制逻辑也很重要。一个常见的错误是：用户直接访问student_course.jsp这个 URL 就能看到课表，完全绕过了登录验证。解决办法是在每个 JSP 页面最顶部检查会话：

<% User currentUser = (User) session.getAttribute("currentUser"); if (currentUser == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } %>

更规范的做法是在web.xml里配置过滤器，统一拦截需要认证的路径。对于课表查询系统这个量级，直接在页面里做检查已经足够用了，但如果你想把代码做得更漂亮，用Filter是更好的选择。

3.3 课表查询核心页面的实现过程

课表查询的页面，可以做成一个 7 列（周一至周日）× 最多 12 行（节次）的二维表格。这个表格在 JSP 里生成的方式比较特殊——它不是直接循环数据库查询结果，而是先构建一个二维数组，再在页面上遍历数组。

核心的 Service 方法如下：

public List<Course> getCoursesByClassAndWeek(int classId, int week) { return courseDao.findByClassAndWeek(classId, week); }

获取到课程列表之后，把它转换成一个二维的占位结构。这里我提供一种经过实践检验的写法——在 Servlet 中直接返回一个List<List<Course>>结构，外层 List 的索引代表星期几，内层 List 代表第几节次：

List<List<Course>> scheduleTable = new ArrayList<>(); for (int day = 1; day <= 7; day++) { List<Course> dayCourses = new ArrayList<>(); for (int section = 1; section <= 12; section++) { dayCourses.add(null); } scheduleTable.add(dayCourses); } for (Course course : courseList) { scheduleTable.get(course.getDayOfWeek() - 1).set(course.getStartSection() - 1, course); }

然后 JSP 页面用 JSTL 标签双循环渲染表格：

<table border="1"> <tr> <th>节次</th> <th>周一</th> <th>周二</th> <th>周三</th> <th>周四</th> <th>周五</th> <th>周六</th> <th>周日</th> </tr> <c:forEach var="section" begin="1" end="12"> <tr> <td>第${section}节</td> <c:forEach var="day" begin="0" end="6"> <td> <c:if test="${not empty scheduleTable[day][section-1]}"> ${scheduleTable[day][section-1].courseName}<br> ${scheduleTable[day][section-1].classroom} </c:if> </td> </c:forEach> </tr> </c:forEach> </table>

这个实现方式的优势在于：无论数据库里课程顺序怎么乱，页面上的表格结构永远是固定的。空单元格显示为空，有课的单元格显示课程名和教室，逻辑非常直观。

如果一门课程跨了多个节次，比如高等数学是第 1-2 节，上面的实现会在第 1 节和第 2 节各显示一次课程名。这个问题有更优雅的解法，可以在渲染时判断end_section，合并单元格，但代码复杂度会明显上升。我的建议是：先跑通基础版本，再把合并单元格作为优化项来做。这个顺序很重要，不要一开始就追求完美而陷入复杂的循环逻辑里出不来。

3.4 单双周判定与周次导航

刚才的代码里有一个int week参数，它是从哪来的？这个值通常由用户在页面上选择，或者由系统自动计算。

我建议的做法是：进入课表查询页面时，默认显示当前教学周，这是通过一个工具类计算得出的：

public static int getCurrentTeachingWeek() { LocalDate today = LocalDate.now(); LocalDate semesterStart = LocalDate.parse("2024-09-01"); long days = ChronoUnit.DAYS.between(semesterStart, today); return (int) (days / 7) + 1; }

然后在页面上提供上一周、下一周的导航按钮，以及一个输入框让用户直接跳转到指定周：

<a href="${pageContext.request.contextPath}/student/course?week=${currentWeek - 1}">上一周</a> <a href="${pageContext.request.contextPath}/student/course?week=${currentWeek + 1}">下一周</a>

这个逻辑虽然简单，但它让课表查询系统从一个静态展示变成了真正可用的工具。学生可以翻看整学期的课程安排，而不是只能看当前这一周。

一个细节：周次参数从request.getParameter("week")获取后，需要做一次数字类型转换和范围校验。如果用户输入week=999或者week=abc，你的代码不能直接崩溃。比较稳健的做法是：

int week; try { week = Integer.parseInt(req.getParameter("week")); } catch (NumberFormatException e) { week = getCurrentTeachingWeek(); } if (week < 1 || week > 20) { week = getCurrentTeachingWeek(); }

有些同学可能会觉得“谁会乱输参数”，但一个系统被用户以各种姿势折腾，是开发者的宿命。提前做好防御性编程，是专业开发者和新手的明显区别之一。

4. 部署上线与常见问题排查

4.1 本地部署与 IDEA Tomcat 集成

在 IntelliJ IDEA 里跑起来这个项目并不复杂。配置步骤如下：

1. 打开Run Configuration，新建一个Tomcat Server > Local。
2. Application server 指向你本地的 Tomcat 目录。
3. Deployment 选项卡，点击加号，选择Artifact，选中以war exploded结尾的那一项。
4. Application context 设置为/course。
5. 运行前确认数据库服务已经启动，且DBUtil里的连接信息正确。

启动之后，浏览器访问http://localhost:8080/course/login.jsp，你应该能看到登录页面。

常见的一个新手困惑是：为什么我项目里明明有login.jsp，访问http://localhost:8080/course/login.jsp却显示 404？这通常是因为 IDEA 没有把 webapp 下的资源文件同步到 target 目录。解决办法是执行一次Build > Rebuild Project，或者检查 Artifact 配置里是否包含了 webapp 目录。

4.2 高频率问题速查表

这个项目里出现频率最高的问题，我整理成了一张表，你在开发过程中遇到对应症状可以到此排查。

4.3 我踩过的几个坑

第一个坑是连接池的滥用。有些教程会教你在DBUtil里用DriverManager.getConnection()工具类获取连接，这种做法在课设里没问题，但在真实业务里会坑死你。每次请求都新建一个数据库连接，在高并发下数据库连接数会迅速打满，整个系统直接瘫痪。正确的做法是使用连接池，比如Druid或HikariCP，然后从池子里借用连接。哪怕是课设项目，我也建议你用Druid，因为它的配置就三五行，但代码的健壮性会好很多。

第二个坑是被 JSP 页面里的 Java 代码牵着鼻子走。我见过有的项目，一个课表页面的 JSP 里有上千行代码，逻辑全部写在<% %>里，页面渲染和数据处理混成一片。改一个小功能，要在几千行里翻找对应位置，改完还可能影响别的功能。后来我把这些逻辑全部抽到 Servlet 和 Service 里，JSP 只用 JSTL 渲染，代码的清晰程度完全变了一个样。写 JSP 的时候你可以问自己一句：这行代码如果挪到 Servlet 里会不会更好？如果答案是肯定的，就果断挪走。

第三个坑是测试不够全面。很多同学在本地测的时候只测了“正常路径”——登录成功，看到课表，完美。但忘了测“异常路径”——密码错了会怎样？没有课的那一周会显示什么？直接访问还没到开学周的课表会怎样？这些边界情况才是真正区分一个系统是玩具还是产品的地方。我在做这个项目的时候，会把边界情况一条条列出来挨个测，确保每一处都不崩、不报错、有合理的提示，才算是真正做完。

4.4 从课设到可用系统的扩展方向

如果你不满足于“交差”，想让这个课表查询系统真正变得好用，有几个方向可以继续深化。

一是加课程冲突检测。现在系统只负责展示课表，管理员录入新课程时，系统不会检查老师是不是在这个时间已经有课、这个教室是不是已经被占用。你可以基于现有的Course数据做一次校验查询，录入时提示“该教室第 3 节已有课程，请重新选择”，这个功能会让系统瞬间从“查询工具”变成“管理工具”。

二是增加课表导出功能。现在很多学校的学生都在用第三方课表 App，如果能把自己的课表导出成 iCalendar 格式（.ics文件），学生就能把它导入手机日历，真正实现“课表随身带”。实现方式也不复杂，只需写一个 Servlet，设置response.setContentType("text/calendar")，然后把课表数据拼接成 iCal 格式的文本输出即可。

三是把页面做成响应式布局。现在大多数用户在手机上查课表，但传统 JSP 页面没有做移动端适配。你可以引入 Bootstrap，让表格在小屏幕上自动横向滚动，或者在导航栏上做一个“移动端模式”的简化页面。这只是前端层面的改造，后端完全不需要动。

这些扩展方向听起来一个比一个复杂，但它们的共同点是都建立在一个分层清晰、结构合理的代码地基上。这就是我反复强调架构和规范的原因——地基打好了，盖多少层楼都不怕；地基是烂泥，盖一层楼都摇摇晃晃。

这个项目做下来，你掌握的不只是一堆 JSP 标签和 JDBC 代码，而是一整套“需求分析 → 数据库设计 → 分层编码 → 测试部署”的完整流程。这套流程是通用的，你以后学 Spring Boot、写微服务、做小程序后端，用的思路都是一样的。工具会变，框架会淘汰，但对数据流的理解和对工程结构的把握，是真正能跟着你走很远的东西。希望这篇分享能让你在动手写“JSP课表查询系统”的时候少一点迷茫，多一点底气。如果卡在某个具体报错上，对照上面的排查表一项一项查，大部分问题其实都有迹可循。