企业官网建设流程全解析

做毕设或者帮朋友跑通一份源码的同学，应该都有同感：JavaWeb 的经典题目每年就那么几个，“JSP企业人事管理系统”绝对是出现频率最高的一类。这题目看起来不复杂——员工增删改查、部门管理、考勤、薪资，似乎随便找份教程就能抄完；可真正动手做的时候，从 IDEA 新建 JSP 项目到数据库设计，从跑通调试到打包部署，每一步都可能卡住一整天。这篇文章就把整个系统的完整链路拆开讲一遍，内容包括数据库表结构怎么设计最合理、核心功能模块的实现顺序、开发环境（JDK + Tomcat + MySQL + IDEA）的搭建细节、从源码到 war 包的部署全过程，以及我在实际调试中踩过的乱码、端口冲突、驱动丢失等典型问题。适合准备毕设答辩、正在学 JSP 课程、或者接手了类似源码但跑不起来的同学参考。按文章里的顺序操作，理论上半天就能从零跑通并部署完成。

1. 这个JSP人事系统到底做了什么：从题目的内核说起

1.1 为什么JSP老技术栈在毕设圈里依然火爆

很多同学不理解，网上 Spring Boot 教程铺天盖地，为什么学校还布置 JSP 项目？我的体会是，JSP/Servlet 是理解 JavaWeb 底层原理最短的路径。一次请求从浏览器发出，经过 Servlet 处理、调用 JDBC 访问数据库、再通过 JSP 渲染页面返回，这个链路没有任何框架包装。学完这一遍，再去看 Spring MVC、MyBatis 都是秒懂。而企业人事管理系统这个题目恰好覆盖了 JavaWeb 的核心知识点：登录会话、权限控制、增删改查、分页查询、多表关联，业务规模又控制在一个学生能独立完成的程度。无论是头歌类的 JavaWeb 实训，还是学校里的课程设计、毕业设计，JSP 题目的出现频率都极高，因为它既能检验基础，又不容易作弊抄网上的复杂框架代码。

1.2 功能边界：一套人事系统需要覆盖的最小业务闭环

我拿到这套源码后，第一件事就是把业务功能理清楚。系统功能边界如下：

• 系统登录：区分管理员与普通员工两种角色。管理员进入后台管理界面，普通员工只能进入个人信息展示页面，查看自己的基本信息、考勤记录和薪资单。
• 部门管理：部门信息的增删改查，员工与部门通过外键关联。
• 员工管理：员工基本信息的维护，包括姓名、性别、岗位、入职时间、联系方式等，支持模糊搜索和分页展示。
• 考勤管理：记录每天的上下班打卡时间，支持按日期、按员工查询，并能统计迟到、早退、缺勤情况。
• 薪资管理：按月生成员工薪资记录，能够调用考勤结果计算实发工资。
• 数据统计：首页展示员工总数、部门数量等汇总信息，提升演示直观性。

业务链路是“部门→员工→考勤→薪资”，每一张表都有一条清晰主线。这也是我建议所有拿到 JSP 毕设题目的人先做的事：不要急着敲代码，先把业务链路画出来。链路清楚了，后面的表设计、Servlet 路由、页面对应关系都不会乱。

1.3 交付物里都有什么：源码、数据库、部署文档怎么配合

这套项目交付时通常包含四样东西：可运行程序、完整源码、数据库 SQL 脚本、调试部署文档。很多新手一上手就习惯直接点开源码看代码，这是顺序反了。正确顺序是：先按部署文档把环境搭好，把数据库脚本导入，把程序跑起来，再对照源码去看每个功能对应的代码位置。跑通之后再读代码，效率会高非常多，因为你已经知道某个页面长什么样，自然能顺着 JSP 文件名找到对应的 Servlet 和 DAO 方法。标题尾缀那一串编号，在项目交易或分享场景里通常只是某次交付版本的生成标识，不用被它绕晕，本质上就是这套文件组合的索引。如果是接手别人的源码，第一件事同样不是看代码，而是先导入数据库脚本，确认数据能查出来。数据通了，程序离跑通就不远了。

2. 开发环境选型：为什么我推荐 JDK 8 + Tomcat 8.5 + MySQL 5.7 的稳妥组合

2.1 版本组合背后那些不写进教程的兼容性问题

JSP 项目对版本兼容性非常敏感。我见过太多同学用新版 JDK 17 配 Tomcat 10，结果启动直接报错，或者页面 EL 表达式完全不解析。原因很简单：Tomcat 10 把 Jakarta EE 的包名从 javax 换成了 jakarta，老项目全部作废；JDK 高版本对反射、模块化的限制也会让老框架报错。所以我使用的组合是：JDK 1.8、Tomcat 8.5、MySQL 5.7。如果一定要用 MySQL 8.0，注意两个点：驱动要用 mysql-connector-java 8.0.x，连接 URL 里要加 serverTimezone=Asia/Shanghai，否则会报时区异常。这个版本组合我在多个项目里验证过，兼容性最稳，网上资料也最多，遇到问题一搜就能解决。

2.2 从零搭建：JDK、Tomcat、MySQL、IDEA 的安装要点

装 JDK 1.8 看似简单，但很多人装了之后到 IDEA 里配置 Tomcat 时才发现找不到 JDK，原因是偷懒跳过了环境变量配置。推荐装完就做三件事：新建 JAVA_HOME 变量，指向 JDK 安装目录；往 Path 里追加 %JAVA_HOME%\bin；然后重新打开命令行窗口，执行 java -version 验证。这里多说一句，下载时要看清 32 位还是 64 位，虽然现在 64 位系统是主流，但选错版本后面全程报错也是常事。

Tomcat 8.5 直接官网下载 zip 包解压即可，Windows 运行 bin 目录的 startup.bat。解压路径不要带中文和空格，比如 E:\Program Files\Tomcat 这种路径后续容易出玄学问题。启动后访问 http://localhost:8080，看到 Tomcat 欢迎页就说明环境通了。如果双击 startup.bat 一闪而过，大概率是 JAVA_HOME 没配好。关服务时用 catalina.bat run 可以直接看控制台报错，比双击 startup.bat 更能定位问题。

安装 MySQL 5.7 时，端口保持默认的 3306，字符集选 utf8mb4，后续基本不用改。不要用 root 空密码去跑项目，单独建一个程序专用账号更稳妥，比如 hrms_user/123456，并给这个账号授予 hrms 库的增删改查权限。如果改用了 MySQL 8.0，注意把账号加密方式改成 mysql_native_password，否则驱动连接时会报认证插件错误。数据库管理工具推荐 Navicat，导入 SQL、看表结构、连库测试都很顺手。

IDEA 版本的选择也有讲究。我建议用 2021.1 到 2022.3 之间的版本，太新的版本 Web 项目向导变化很大，一时难以适应；太旧的版本对高版本 JDK 的适配有问题。装完之后在 Settings 里确认 Maven 的本地仓库路径和镜像配置，避免等项目用到 Maven 依赖时卡在下载环节。社区版就能跑普通 JSP 项目，如果涉及 Servlet 的代码跳转，Ultimate 版体验会更好。

2.3 把源码导入 IDEA 的正确姿势

这套源码是传统 JSP 三层结构：src 目录放 Java 源码，web 目录放 JSP 页面和静态资源，WEB-INF 下放 web.xml 和 lib 依赖包。导入方式建议选择 File -> New -> Project from Existing Sources，或者直接在 IDEA 里以 Maven 方式导入带 pom.xml 的项目。不要直接把整个文件夹 Open 进来，那样容易丢失项目结构配置。

导入之后有两件事容易漏。第一是配置项目结构：在 Project Structure 里把 web 目录标记为 Web 资源目录，在 Artifacts 里生成 war exploded 包。第二是把 WEB-INF/lib 下的所有 jar 包添加到类路径中。漏掉第二步的直接后果是运行时 NoClassDefFoundError，最典型的就是 mysql-connector-java.jar 没进来，启动报 ClassNotFoundException: com.mysql.jdbc.Driver。

对于带 Maven 的 JSP 项目，pom.xml 里要特别注意依赖的 scope。传统 JSP 项目里 servlet-api、jsp-api 这两个依赖如果打包进 war，会和 Tomcat 自带的类冲突，必须声明为 provided。这个细节直接决定打包出来的 war 包能否在外部 Tomcat 上正常启动，也是我在 5.2 节会再次强调的重点。

3. 数据库设计：六张表如何撑起人事管理这条完整业务线

3.1 设计目标：字段够用、关系清晰、答辩好讲

数据库是整套系统的地基。我理需求时发现，网上不少源码的表结构五花八门：有的把员工和用户混在一张表，有的没有部门表，直接用字符串存部门名。这种设计虽然也能跑，但答辩时一问多表查询就露馅。我的方案是围绕“员工”这个核心实体设计六张表：admin 管理员表、dept 部门表、employee 员工表、attendance 考勤表、salary 薪资表，以及一张用于存储系统基础参数的 config 表。

设计原则有三条。第一，每张表有独立自增主键，int 类型，不做复杂业务主键，课设级别系统简单可靠优先。第二，表间关联用外键逻辑实现，通过存储另一张表的 id 来关联，不强制开启数据库级外键约束，增删改查的操作灵活性更高。第三，每张表都带 create_time 字段，虽然部分业务没用到，但答辩时问字段设计理由，随时能给出合理回答。

3.2 核心表结构逐张拆解

dept 部门表字段最简洁：id、dept_name、dept_desc、create_time。dept_name 要加唯一索引，防止管理员录入重复部门。employee 员工表是核心，字段包括 id、emp_no 员工编号、emp_name、gender、phone、email、dept_id、position 岗位、hire_date 入职日期、salary_base 基本工资、status 在职状态、create_time。关键的关联字段是 dept_id，它指向 dept 表的 id，实现多对一关系。Java 代码里做关联查询时只需一条 LEFT JOIN 就能拿到部门名称。

attendance 考勤表设计为每日一条记录：id、emp_id、att_date 日期、check_in 上班时间、check_out 下班时间、status 状态（正常/迟到/早退/缺勤）。salary 薪资表按月一条记录：id、emp_id、salary_month 月份、base_salary 基本工资、bonus 奖金、deduction 扣款、actual_salary 实发工资、create_time。deduction 扣款字段由考勤模块计算后写入，这两个模块形成闭环，也是答辩时最有话讲的业务逻辑点。

剩余两张表相对简单。admin 管理员表字段为 id、username、password、real_name，支撑登录认证；config 配置表通常放系统名称、版本号、默认分页条数这类可调参数，虽然只有几条数据，但避免了在代码里写死配置。六张表各有归属，没有冗余表，评审听你讲解时思路会很清晰。

3.3 建库建表脚本与初始化数据

项目交付的数据库脚本通常包含三部分：建库语句、建表语句、初始化数据。执行时建议用 Navicat 直接打开 .sql 文件运行，不要复制到命令行执行，换行和注释格式容易出问题。脚本开头一般长这样：

CREATE DATABASE IF NOT EXISTS hrms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hrms; CREATE TABLE dept ( id INT PRIMARY KEY AUTO_INCREMENT, dept_name VARCHAR(50) NOT NULL, dept_desc VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

初始化数据部分建议预置一条管理员账号（比如 admin/123456，密码使用 MD5 加密后的密文）、三个部门、五名员工和几条考勤数据。预置数据的价值在于：系统一跑起来首页统计就有数可看，登录后做增删改查演示时界面不单调，答辩前也不用临时敲一堆测试数据。注意员工编号、部门名称这些基础数据尽量贴近真实，比如技术部、人事部、财务部，比纯 abc 更有说服力。

3.4 连接池与数据库工具类

业务代码里日常打交道的是 JDBC。这套系统用 db.properties 保存数据库连接配置，包含驱动类名、URL、用户名、密码，再写一个 DBUtil 工具类负责加载配置、获取连接、关闭资源。如果项目里引入了 druid 连接池，核心配置代码只有几行：

DruidDataSource ds = new DruidDataSource(); ds.setDriverClassName("com.mysql.jdbc.Driver"); ds.setUrl("jdbc:mysql://localhost:3306/hrms?useUnicode=true&characterEncoding=utf8"); ds.setUsername("hrms_user"); ds.setPassword("123456"); // 每次需要连接时调用 ds.getConnection() 即可

使用连接池比每次 DriverManager.getConnection 的方式稳定得多。至少不用频繁开关数据库连接，页面访问速度有肉眼可见的提升。答辩时老师问“数据库访问这块怎么优化的”，答案就现成：连接池复用、预编译 SQL、分页查询限制返回条数，这三条足够撑起场面。

4. 核心功能模块的实现顺序与关键代码思路

4.1 分层结构：为什么从 Servlet 到 JSP 要拆成四层

拿到源码第一步是认目录。这套系统走的是标准 MVC 分层：entity 实体类对应数据库表；dao 数据访问层负责 JDBC；servlet 控制层接收请求、调用业务、跳转页面；JSP 作为视图层展示数据；util 工具类放 DBUtil、MD5 等公共方法。如果不分层，所有代码往 Servlet 里写，前期确实快，但到了加部门管理、考勤管理模块时，代码重复率极高，一个人维护都嫌累。

实现顺序建议从实体类开始，然后一个模块一个模块推进：登录认证、部门管理、员工管理、考勤管理、薪资管理。每个模块内部是同一套流水线：写一个 DAO 方法，写一个 Servlet 处理请求，写一个 JSP 页面展示结果。一个模块完整跑通后再做下一个，比并行写多个模块更不容易乱。

4.2 登录模块：Session 会话与 Filter 权限拦截

登录是系统的门面。用户提交表单后，LoginServlet 接收用户名和密码，密码先做 MD5 加密，再调用 AdminDAO 查库比对，成功就把用户信息放入 Session，重定向到首页；失败则返回错误提示。关键点是权限控制，不能只靠每个 JSP 页面里判断 Session 是否为空，要用 Filter 统一拦截。在 web.xml 里配置 LoginFilter，把受保护路径统一放进 /admin/ 前缀下，在 doFilter 方法里检查 Session：

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; HttpSession session = req.getSession(); Object user = session.getAttribute("loginUser"); if (user == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); }

这段代码是大多数 JSP 毕设项目权限控制的标准写法，值得好好读一遍。注意两点：Filter 的 url-pattern 要精确，通常只拦截 /admin/*，同时放行登录页、CSS、JS 等静态资源，否则会出现页面死循环跳转。另外 Session 里存放的对象最好用统一常量名，比如 loginUser，这样所有模块取会话信息时不会拼错字符串。我把会话常量单独放在一个工具类里，虽然多写了几行代码，但后续扩展角色权限时省了很多事。

4.3 员工管理：分页查询、模糊搜索、表单校验

员工管理是工作量最大的模块，因为它包含最完整的增删改查。新增时从表单获取字段后 insert，删除时根据 id 执行 delete，编辑时先按 id 查出原数据回显到表单，提交后执行 update。这里有两个细节最值得讲。

第一个是分页查询。员工列表如果一次性查询全部记录，数据少时没感觉，数据多了页面会明显卡顿。实现思路是 PageBean 封装当前页码 currentPage、每页条数 pageSize、总记录数 totalCount、总页数 totalPage 和当前页数据 list，SQL 使用 LIMIT：

SELECT * FROM employee e LEFT JOIN dept d ON e.dept_id = d.id ORDER BY e.id DESC LIMIT ?, ?

计算出偏移量 (currentPage - 1) * pageSize 传入预编译的 PreparedStatement，就能实现标准分页。这是 JSP 项目里最常被答辩老师深挖的知识点，建议背熟。

第二个是模糊搜索。搜索框一般提供按姓名、按部门两个条件，动态拼接 SQL 时判断条件是否为空，再用 % 包裹关键字：

String sql = "SELECT * FROM employee WHERE 1=1"; if (name != null && !"".equals(name)) { sql += " AND emp_name LIKE ?"; params.add("%" + name + "%"); }

先拼一个恒真的 WHERE 1=1，后续条件直接用 AND 追加，省去判断拼接位置的问题。这个技巧用起来非常省心，也避免了一大堆 if-else 处理 SQL 拼接顺序。

4.4 考勤与薪资模块的业务联动

考勤模块的 DAO 层主要做两件事：打卡记录插入、按日期和员工查询列表。业务中常见一个批量生成逻辑：管理员选择部门和月份，系统遍历该部门员工，为每人生成当月每天的考勤记录，默认状态为正常。这个批量操作用循环就能实现，但 SQL 执行次数多，建议用 PreparedStatement 的 addBatch/executeBatch 批量添加，几百条数据一次提交，性能好很多。

薪资模块是整套业务逻辑的落点。计算实发工资时，规则可以简化成：实发工资 = 基本工资 + 奖金 - 缺勤天数 × 单日工资。单日工资按基本工资除以当月工作日估算，缺勤天数从考勤表中按月份聚合查询得到。这样，数据库设计、考勤逻辑、薪资计算三者就形成了一条完整的数据链路。答辩时能从表结构一路讲到业务代码，评审老师会认为你有清晰的全局观。

5. 从源码到跑通：IDEA 调试与 war 打包部署完整实操

5.1 在 IDEA 里配置 Tomcat 并实现热部署调试

拿到源码并导入 IDEA 后，第一步是在 IDEA 里配置 Tomcat。打开 Run -> Edit Configurations，点击加号选 Tomcat Server -> Local，在 Application server 一栏选择本地 Tomcat 8.5 目录。然后在 Deployment 标签页添加 Artifact，选择该项目的 war exploded，Application context 设置为 /hrms。这里的上下文路径就是后续访问路径，配置成 /hrms，访问地址就是 http://localhost:8080/hrms。很多同学部署完访问 404，就是因为记错了上下文路径。

配置完成后直接启动，IDEA 会自动把项目编译、打包、发布到 Tomcat，并打开浏览器。使用 war exploded 的好处是支持 JSP 热部署，修改 JSP 页面后刷新浏览器就能看到改动，不需要重启 Tomcat；但修改 Java 源码后，建议手动重启调试服务，避免部分 IDE 版本热加载不彻底。

5.2 把项目打成 war 包：传统 JSP 项目打包要点

开发调试完毕，最后一步是导出可部署的 war 包。在 IDEA 中依次点击 Build -> Build Artifacts，选择 war 并点击 Build，完成后在项目 out/artifacts 目录下就能看到 hrms.war。打包之前务必检查 Artifacts 配置里是否把依赖库包含进去，如果 jar 包没有打进包内，war 发到其他机器上启动时会报各种 ClassNotFoundException。

对于带 Maven 的 JSP 项目，打包命令是 mvn clean package，但要把 servlet-api 和 jsp-api 的 scope 设置为 provided。这一步在上文环境部分提过，实际操作中翻车率极高：不少同学把这两个依赖打成默认的 compile 放进包，war 部署到外部 Tomcat 后直接启动失败，原因是类冲突。所以打包前先检查 pom.xml，确认这两个依赖没有被打进去。

5.3 部署到独立 Tomcat 与数据库初始化完整流程

将 hrms.war 复制到 Tomcat 的 webapps 目录下，启动 Tomcat 后会自动解压，访问 http://localhost:8080/hrms 就能看到系统首页。这里有个常见认知差：外部 Tomcat 和 IDEA 内置 Tomcat 的部署目录不同，外部部署时项目上下文路径由 war 包文件名决定。比如 hrms.war 的上下文就是 /hrms，想改路径可以修改 conf/server.xml 中的 Context 配置。

数据库初始化流程相对固定：在目标机器安装 MySQL，执行 hrms.sql 脚本，把库表结构和初始化数据全部准备好；然后修改项目中的 db.properties，把 jdbc.url、用户名、密码改成目标机器实际配置。如果数据库在另一台服务器，把 localhost 换成对应 IP，并确保目标机器 3306 端口在防火墙中放行。整个部署过程中版版本一致性是最容易忽视的一点：目标机器的 JDK、Tomcat、MySQL 版本尽量与开发环境保持一致，版本跨界很容易触发兼容问题。

6. 跑不起来别慌：我实测中踩过的典型坑与完整排查链路

6.1 中文乱码：页面、数据库、文件编码三处同步检查

乱码问题绝对是 JSP 项目报错第一名。我实际调试时遇到过三种表现：页面输出问号乱码、数据库里存进去的中文变问号、下载的文件名乱码。三种情况原因各不相同。

页面显示乱码常见于 JSP 文件第一行没有声明 pageEncoding，或声明编码与文件实际编码不一致。解决办法是每张 JSP 页面头部加上：

<%@ page contentType="text/html; charset=UTF-8" language="java" pageEncoding="UTF-8" %>

同时在 web.xml 里配置 CharacterEncodingFilter，强制所有请求和响应使用 UTF-8。数据库中文变问号，通常是连接 URL 里没带 characterEncoding 参数，或者建库时字符集不是 utf8mb4。我在 3.3 节强调过，建库语句必须明确指定 CHARACTER SET utf8mb4。文件编码则要检查 IDEA 的 File Encodings，把 Global Encoding、Project Encoding、Properties Files 都改成 UTF-8。三处都检查完，乱码问题基本能根治。

注意：检查乱码问题时，优先看数据库连接 URL 参数，这是新手最容易漏掉的一环。

6.2 JDBC 驱动找不到与 mysql-connector 版本不匹配

报错 java.lang.ClassNotFoundException: com.mysql.jdbc.Driver，十有八九是 jar 包没有正确导入。传统 JSP 项目需要把 mysql-connector-java.jar 放进 WEB-INF/lib 目录，并在 IDEA 中 Add as Library。另一个更隐蔽的坑是版本不匹配：MySQL 8.0 必须使用 8.0.x 驱动，驱动类是 com.mysql.cj.jdbc.Driver；MySQL 5.7 用 5.1.x 驱动即可，驱动类是 com.mysql.jdbc.Driver。如果用 5.1 驱动去连 MySQL 8.0，会报 SSL 连接错误或认证插件不兼容。

我的建议是把驱动版本和数据库版本绑定考虑：数据库 5.7 就用 mysql-connector-java-5.1.49.jar，数据库 8.0 就用 mysql-connector-java-8.0.28.jar，别在驱动这件事上图省事。

6.3 Tomcat 端口被占用与项目启动失败

启动时报 Address already in use: JVM_Bind :8080，是最常见的启动失败原因。在 Windows 上用 netstat -ano | findstr 8080 查到占用端口的 PID，再到任务管理器结束对应进程即可。如果结束不掉，比如被系统服务占用，就干脆修改 Tomcat 的 server.xml 把 HTTP 端口改成 8081。不过要注意，修改端口后上下文路径和端口在答辩演示时不要频繁变动，容易把自己绕晕。我的排查顺序是：先 netstat 查端口，确认占用进程后直接结束；结束不了再改端口，不要一上来就乱改配置。

6.4 部署到外部 Tomcat 后 404 与访问路径错乱

IDEA 里能跑，部署到外部 Tomcat 却 404，本质上是 Application context 没对上。外部部署时，Tomcat 自动解压 hrms.war 后，上下文路径就是 /hrms，如果代码里写死了 /hrms 前缀就容易出问题。正确做法是推荐统一使用 request.getContextPath() 动态拼接项目路径，这样开发环境和部署环境的上下文不一致时也不会出错。

另一类 404 是 Artifacts 配置错误导致的：IDEA 里 Artifacts 类型选成 war exploded，但没有配置正确的输出目录，编译产物缺失 web.xml，部署时找不到配置。检查方法很直接：解压打包好的 war 包，看 WEB-INF 下有没有 web.xml，classes 目录下有没有 .class 文件，缺哪个就回 IDEA 的 Project Structure 检查 Artifacts 配置。

6.5 数据库连接失败：Access denied、时区、驱动三类原因

数据库连接失败是最难一言以蔽之的问题，因为现象相似但原因多样。我按出现频率排序，给出一份排查表和对应解法：

排查这类问题有个笨但有效的套路：写一个独立的 Java 类只做一件事，获取数据库连接并查询一个简单字段，把数据库从业务系统中剥离出来单独验证。数据库层通了，再回到 Tomcat 里启动项目，问题范围立刻缩小一半。

7. 答辩与验收视角：如何把项目工作量清晰展现出来

7.1 演示场景的设计比功能本身更重要

我帮学弟学妹做过不少模拟答辩，发现一个共性：功能全部实现了，但演示时手忙脚乱，效果大打折扣。答辩演示建议按这个顺序走：先登录管理员账号进入首页，重点展示首页统计数字；然后进入部门管理，演示新增一个部门；接着进入员工管理，演示分页、搜索、编辑、删除全流程；再切到考勤管理，演示按日期查询和考勤状态统计；最后到薪资模块，展示工资计算与考勤的联动结果。整个流程控制在十分钟左右，每一步操作前想好一句话解释“这是什么页面、为什么这样设计”，比临时翻代码靠谱得多。

演示用的数据一定要提前准备。最开始我用的是一组随意的测试数据，结果页面上数字对不上逻辑，被老师当场问住。后来我把数据统一成有业务含义的样例：部门有技术部、人事部、财务部，员工有不同岗位和入职时间，考勤数据覆盖正常、迟到、缺勤三种状态，统计结果就变得可以解释了。

7.2 答辩老师最爱问的技术点：提前组织好两分钟的说法

帮人模拟答辩的次数多了，你会发现评委老师的问题并不会飘到天上去，来来去去集中在数据库设计、JavaWeb 基础、项目业务逻辑三个方向。与其背一堆概念，不如针对高频问题准备一段两分钟的说法。回答时注意一定要结合本项目具体例子，比如说到权限就提登录用的 Filter 拦截，说到分页就提员工列表的 LIMIT 查询。空谈定义最容易被扣分，结合项目实际才是加分项。

数据库方向的问题集中在表设计：为什么这几张表？外键关系怎么体现？数据量大时怎么优化？答表设计时抓住一条主线：部门独立成表避免冗余，员工表通过 dept_id 关联部门，考勤和薪资按月挂接员工。优化方向提分页 LIMIT、连接池、索引。JavaWeb 基础方向的问题有 Servlet 生命周期、JSP 和 Servlet 区别、Session 和 Cookie 区别、Filter 作用，这类基础题把生命周期阶段、状态保持机制、过滤器链执行顺序各准备一段话即可。

业务方向最常被追问的是考勤和薪资怎么联动、权限控制怎么做、员工删除时考勤记录怎么办。联动问题就顺着“考勤表按员工和日期存状态，薪资模块按月聚合缺勤天数再算扣款”这条链路讲，能讲清楚就超过大部分只会背模板的人。员工删除属于设计取舍题，说明你考虑过数据一致性即可，比如删除员工时同步删除或保留考勤记录并给出提示，理由充分就行。提前把每个问题过一遍，答辩时自然有底气。我见过不少代码写得很好但表达混乱的，根源就是没提前组织语言，这一点千万别忽略。

7.3 如果想进阶：这套系统的三种扩展方向

做完这套系统还想加亮点，我建议从三个方向任选一个。一是引入 Spring Boot，改造成 Spring Boot + JSP 或 Spring Boot + Thymeleaf 的架构，让技术栈贴近企业实际。SpringBoot 确实可以集成 JSP，只需把视图放在 src/main/webapp 目录并引入相应依赖，网上教程也很多。二是引入 Redis 管理 Session 和页面缓存，既提升性能又展示新技术。三是加一个基于 ECharts 的统计报表页面，把考勤、薪资数据用图表展示，演示效果会非常亮眼。

这三个扩展方向任选其一，项目含金量都会上升一个档次。但前提是先把现有系统的业务逻辑吃透，不要为了炫技而堆砌框架。框架只是工具，把人事管理这条业务链路说明白，才是项目的根基。

最后分享一个实际体会：JSP 这套技术栈虽然老，但它的价值恰好在于没有任何魔法。每个页面、每次数据库访问、每次请求转发都是显式可见的，你在这个项目里搞清楚的分层思想、JDBC 的增删改查、会话状态管理，会在真正进入 Spring 生态时变成最重要的底子。跑这套系统时别怕报错，报错越早遇到的类型越多，后面答辩被问倒的概率就越低。我自己是从一个连 Tomcat 都不会配置的学生过来的，这些坑都替你踩过了，按上面的顺序来，半天之内就能从代码跑通到部署完成。如果中途卡住，优先回到环境、数据、路径三个关键词上排查，百分之九十的问题都能解决。