企业官网建设流程全解析

简介：面向需要搭建请假管理系统或完成课程设计的开发者，压缩包提供了一套可直接落地的完整方案，涵盖源码、原型与数据库三部分，适合用来理解请假申请、审批、销假等典型业务流程，也可作为二次开发或毕设改造的基础。包体共4个文件，包含2个zip工程压缩包、1个sql数据库脚本和1个pdf说明文档，压缩包整体大小约14.28MB，结构清晰，便于按模块查看。其中sql脚本可快速还原数据表，zip内含前后端代码与页面原型，pdf则辅助梳理配置与运行细节，也可在现有流程上补充多级审批等逻辑。目前已有1036人学习下载，对入门Java/Web开发或需要快速交付课设项目的同学颇具参考价值，拿到的是一套从界面原型到数据存储均齐全的请假管理系统资源，可用于本地部署、功能拓展及课程答辩演示。

1. 这套请假管理系统能帮你省掉一个完整课程设计的工作量

上个月有位读者找我，说毕设抽到的题目是请假管理系统，手里除了一份指导老师的题目清单，什么都没有。我让他先搞清楚自己拿到的资源是什么形态：如果是“源码+原型+数据库”三件套，那基本等于把一个能演示、能答辩、能改二开的完整工程摆在了面前。这套请假管理系统正是这样的结构，主工程在practice.zip里，数据脚本是leaverecords.sql，另外配了一份请假管理系统.pdf设计文档，写需求、画原型、讲流程都用得上。你不需要从零搭框架，也不用自己设计表结构，工作量集中到环境配置、代码阅读和按自己学校格式改文档这三件事上。适合课程设计、毕业设计需要演示系统的人，也适合刚接触 Java Web 想读懂一套真实业务代码的初学者。

2. 先把三件套拆开：源码管业务、SQL 管数据、PDF 管验收标准

拿到压缩包别急着导 IDEA，先把里面几个文件的作用边界分清楚。源码、数据库脚本、设计文档三者各自解决不同阶段的问题：源码决定系统能做什么，SQL 决定数据怎么存，PDF 决定验收时你要还原哪些功能。我拆过不少这类课程设计包，最常见的问题是顺序反了，上来就改代码，结果数据库结构没对上，越改越乱。

2.1 practice.zip 主工程结构：弄懂登录到审批的代码主线

解压practice.zip后，你能看到典型的 Java Web 分层结构。不管它是用 Servlet 还是 Spring MVC 写的，包里基本会按dao、service、entity、servlet/controller、jsp这几层组织。先阅读代码别从第一行看起，而是按“登录 → 用户校验 → 发起请假 → 审批流转”这条主线找文件。登录功能一般在servlet或controller包下的LoginServlet/UserController这类文件里，通过请求参数拿到用户名和密码，再调用 service 层去匹配数据库。

// 登录校验核心逻辑，路径：src/com/example/servlet/LoginServlet.java protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String userName = request.getParameter("username"); String passWord = request.getParameter("password"); UserService userService = new UserService(); User user = userService.login(userName, passWord); if (user != null) { // 登录成功，把用户对象放进 session，后续审批人判断要靠这个 request.getSession().setAttribute("currentUser", user); response.sendRedirect("index.jsp"); } else { // 登录失败，回登录页并带错误信息 request.setAttribute("errorMsg", "用户名或密码错误"); request.getRequestDispatcher("login.jsp").forward(request, response); } }

这段代码里有几个值得留意的点。setCharacterEncoding("UTF-8")必须放在读取参数之前，否则表单里的中文姓名、请假事由到了后端就乱码，这一点在第四部分还会遇到。userService.login()封装了查询逻辑，真正执行的 SQL 在 dao 层，查的是user表，密码比对多数是明文匹配，这也是课程设计代码里的常见现象，二开时要改成 MD5 或加盐哈希，否则答辩时被问安全方案会答不上来。

阅读源码时建议在 IDEA 里用 Ctrl+左键跳到 service 和 dao 实现，把“页面 → Servlet → Service → DAO → SQL”这条链路画出来。我一般会把每个 jsp 页面对应的 Servlet 路径记在一张纸上，比如leave_add.jsp对应LeaveAddServlet，后面拿 PDF 原型验收功能时，就能直接找到每一个功能的实现入口。

2.2 公共表结构解析：从 SQL 脚本看系统怎么组织请假业务

leaverecords.sql是这个系统里最不该跳过的东西。用文本编辑器打开它，先扫一遍建表语句，你会发现请假系统的表设计就这么几大类：用户表、请假单表、请假类型表、审批记录表。用户表通常长这样：

-- 用户表：账户信息和默认角色 CREATE TABLE `user` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `username` VARCHAR(32) NOT NULL COMMENT '登录名', `password` VARCHAR(32) NOT NULL COMMENT '密码', `real_name` VARCHAR(32) NOT NULL COMMENT '真实姓名', `role` TINYINT(4) NOT NULL DEFAULT '2' COMMENT '角色：1管理员 2普通员工', `dept_id` INT(11) DEFAULT NULL COMMENT '部门ID，行政归属', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

角色字段用数字而不是字符串，是这套系统里最简化的设计决策。role=1是管理员，role=2是普通员工，请假审批时就把当前用户角色拿来判断能不能通过。请假单表里一定会有leave_type、start_time、end_time、reason、status这些字段，其中status是整个业务流转的关键，常见取值是 0 待审批、1 已通过、2 已驳回。

我看这个 SQL 文件时会额外做一件事：把所有CREATE TABLE语句的建表顺序抄下来，因为表之间有外键依赖，先建dept后建user，先建user后建leave_record，顺序反了导入必报错。脚本里的INSERT语句是给系统准备的基础数据，至少会有一个管理员账号和一个测试员工账号，登录时用的就是这些初始账号，答辩前可以改成自己姓名的账号。

2.3 请假管理系统.pdf：把设计文档当成验收清单而不是摆设

很多同学拿到 PDF 就再也不打开，其实这份文档的价值比源码还大。它里面一般包含需求分析、用例图、部分界面原型截图和数据库说明，答辩时老师问“你的系统为什么这么设计”，答案全在文档里。我的习惯是把 PDF 里的功能列表提取出来，做成一张验收清单，然后逐个去运行中的系统里点一遍，每确认一个功能就打个勾。

如果 PDF 里某个模块在两个页面中出现，说明它被设计为复用页面，运行验证时就要多测一遍边界情况。比如“按日期查询请假记录”可能在员工端和管理端都有，但管理端应该看到全部门记录，员工端只看到自己。这套 PDF 就是给运行环境做的验收标准，没有它，你根本不知道代码里的功能哪些是故意做出来的，哪些是意外产生的半成品。

3. 一小时跑通全流程：从 SQL 导入到 Tomcat 部署的六步联调

拆完资源就要动手让它跑起来。我按 MySQL 5.7 + Tomcat 8.5 + JDK 1.8 的环境来操作，这也是这类课程设计最稳妥的搭配。整个流程六步：装环境、导 SQL、改配置、部署工程、启动 Tomcat、用 PDF 清单对照功能验证。每一步都很机械，但只要错了就能在上一步日志里找到答案。

3.1 环境准备：JDK、MySQL、Tomcat 的三件套安装清单

先确认机器上有没装齐这三样。命令行里执行java -version能看到 1.8 就行；MySQL 用 5.5 到 5.7 都可以，太新的版本比如 8.0 会因为认证插件的问题导致旧驱动连不上，这类项目里最常见的翻车点就是版本不匹配。Tomcat 用 8.0 或 8.5，别用 Tomcat 9 或 10，它们的包名和 Servlet 版本有变化，旧的 web.xml 头可能识别不了。

版本确认之后，把 Tomcat 解压到纯英文路径，比如D:\apache-tomcat-8.5.xx，千万别放进带中文和空格的目录，否则后面的 classpath 和日志解析都会变得很玄学。MySQL 装好后要记好 root 密码，后面导 SQL 要用。

3.2 导入 leaverecords.sql：两步命令加字符集参数

打开命令行终端，先建一个专门的数据库，再导入脚本，这是避免unknown database报错的标准做法。不要直接source leaverecords.sql，因为脚本里不一定写了CREATE DATABASE，一旦没有，你会被一句语法错误卡住。

# 第一步：登录 MySQL，创建数据库 mysql -u root -p # 进入 MySQL 后执行 CREATE DATABASE leave_db DEFAULT CHARACTER SET utf8mb4; USE leave_db; # 退出 mysql 客户端，再执行导入 mysql -u root -p leave_db < D:/path/to/leaverecords.sql

这条命令里<表示把 SQL 文件内容重定向给 mysql 客户端执行，leave_db是目标库名。注意两个细节：一是路径别带中文；二是如果你的脚本里本身就有CREATE DATABASE语句，导入时可以不建库直接 source，但课程设计脚本通常没这么全，所以多数情况下我建议先建库再导入。导入完成后执行SHOW TABLES;，能列出来 user、leave_record 这些表名，就说明成功了一大半。

3.3 数据库连接配置：驱动包位置与 jdbc.properties 参数

源码怎么知道数据库密码？通过一个配置文件。在src目录下找db.properties或jdbc.properties，用编辑器打开，你会看到类似这样的内容：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/leave_db?useUnicode=true&characterEncoding=utf-8 jdbc.username=root jdbc.password=yourpassword

jdbc.url里的localhost:3306/leave_db对应本机 MySQL 和刚才写的库名；useUnicode=true&characterEncoding=utf-8保证了中文写入查询不出乱码，这个参数必须保留；jdbc.password要改成你自己机器的 root 密码。改完之后检查一下WEB-INF/lib目录下有没有mysql-connector-java-*.jar，没有就要放一个 5.1.x 版本的驱动包，否则运行时会报找不到驱动类。

我一般改完配置后会顺手做一次测试：在 MySQL 里执行SELECT * FROM user;，确认用户名密码字段存在，并在系统里准备一个已知的用户名密码。这样等会启动 Tomcat，直接用这组账号登录，能登录就说明 Java 到 MySQL 的整条链路已经通了。

3.4 部署到 Tomcat：war 包方式与目录方式的选择

源码工程分两种形态，一种已经编译成 war 包，一种是 IDEA 工程目录。war 包直接拷进 Tomcat 的webapps目录，启动后自动解压；目录方式则要把编译后的 web 根目录路径配到 Tomcat 的conf/server.xml里。我更建议用 war 包方式，因为课程设计代码大多不保证 IDE 环境统一，war 包是新机器上最容易跑通的形态。

# 启动 Tomcat（Windows） D:/apache-tomcat-8.5.xx/bin/startup.bat # 查看日志，确认有没有异常 tail -f D:/apache-tomcat-8.5.xx/logs/catalina.out

Windows 下用startup.bat，Linux/mac 用startup.sh。日志里看到Application Startup completed或者Deployment of web application archive结束，再进浏览器。访问地址一般是http://localhost:8080/practice/，practice是工程名，跟 war 包名一致。打开首页后用你配置的账号登录，如果跳到主页且能发起请假申请，整个系统就算活过来了。

3.5 用 PDF 功能表做第一轮验收：按模块点完才算数

系统能登录只是第一步，把 PDF 里的功能清单过一遍才算真正跑通。按我 2.3 节列的表格，逐项执行：发起请假申请，选一个假别，填开始时间、结束时间、事由，提交后面试列表；再用管理员账号进去，看待审批列表里有没有这条记录，点同意后回到员工账号刷新，状态应该变成已通过。

第一轮验收最容易漏的是修改密码和退出登录这两个隐藏功能，很多源码里做了但没放链接，要手动敲 URL 才能访问。打开 PDF 里面关于“系统管理”的章节，如果提到“修改密码”，就去源码里搜changePassword或者PasswordServlet，把 URL 路径记下来直接访问。这一轮走完，你对这套系统能干什么、不能干什么就已经非常清楚了。

4. 避坑排查：乱码、驱动、端口、SQL 导入这四个问题最多

课程设计系统代码老旧但套路固定，出问题的地方也就那么几个。我拆过几套类似的资源后，把最容易踩的坑整理成现象、原因、解决三段式。你按这个顺序排查，成功率很高，剩余少数情况查日志就行了。

4.1 登录后中文姓名显示问号，新增的请假事由也是问号

现象：登录系统后页面右上角真实姓名变成一串???，提交请假单后再列表看中文全是问号。原因：HTTP 请求传参编码没统一，或者数据库连接 URL 没有指定字符集。这类旧项目常见的配置是页面用 GBK，后端却按 UTF-8 解码，两个地方不一致就必然乱。解决：先把 MySQL 连接 URL 后面加useUnicode=true&characterEncoding=utf-8，再把所有 jsp 页面头部统一为<%@ page contentType="text/html;charset=UTF-8" %>，然后在request.setCharacterEncoding("UTF-8")之前再设一次。如果数据库里已存了乱码数据，删掉重建表再导一次leaverecords.sql，因为历史乱码无法自动恢复。

4.2 Tomcat 启动后访问页面报 500，日志提示找不到类

现象：浏览器能打开登录页，输入账号密码点登录却直接 500，Tomcat 日志里有ClassNotFoundException: com.mysql.jdbc.Driver。原因：MySQL 驱动 jar 不在WEB-INF/lib里。源码压缩包为了瘦身，很多时候把 jar 包文件删了，只留下代码。解决：到网上下一个mysql-connector-java-5.1.49.jar，放进工程的WEB-INF/lib目录，然后停止 Tomcat，删除work/Catalina/localhost/practice缓存目录，再重新启动。这里有个细节：放完 jar 必须重启，Tomcat 不会热加载 lib 下的新 jar 文件。

4.3 8080 端口被占用，Tomcat 一启动就崩

现象：执行startup.bat秒退，命令行提示或者日志里出现Address already in use: JVM_Bind，确认是 8080 端口被别的进程占了。原因：本机装了其他 Java 应用、某个残留 Tomcat 没关，或者 IDE 内置服务占用了端口。解决：命令行执行netstat -ano | findstr 8080，找到占用进程的 PID，打开任务管理器结束它。如果该进程不能杀，就改 Tomcat 启动端口：编辑conf/server.xml，把 Connector 标签的port="8080"改成8899，访问地址换成http://localhost:8899/practice/。

4.4 SQL 导入时报错，提示Table 'user' already exists

现象：导入leaverecords.sql执行到一半报错，之前有些表已建好，重新导入时因为表已存在直接中断。原因：机器上之前跑过别的项目，数据库里已经有同名表；或者你自己手动建过表。CREATE TABLE没带IF NOT EXISTS，第二次执行必然冲突。解决：先执行DROP DATABASE leave_db;再重建库、再导入，确保全新环境。注意如果原来的库里还有其他数据，这种操作会全部清掉，我一般在测试环境直接这么干，确认表结构和数据是你需要的再保留。

5. 把演示级系统改成答辩级：多级审批流程与数据库字段扩展

系统跑通只是个起点，多数课程设计的问题是“功能太浅”，比如所有请假申请只经过一个管理员审批，没有部门经理、总经理这层概念。想提升答辩含金量，我建议从两个方向下手：一是把审批流程改复杂，二是让数据模型支撑这个复杂度。这两个改动都依赖你对leaverecords.sql和源码结构已经足够熟悉。

第一个改动是加审批等级。当前请假单的status字段只有 0、1、2 三个值，你先在leave_record表加一个current_approval_level字段，默认 1，表示当前需要第几级审批人处理。请假单表结构扩展后，审批 Servlet 读这个字段，等于 1 就找部门经理账号审批，等于 2 就找总经理账号审批。要支撑这个逻辑，还需要在部门表或用户表里加一个approval_level字段，表示这个人能批到第几级。每次审批通过后，把current_approval_level加一，直到超过最大层级就置为通过。这个过程完整走下来，系统就从“单层审批”变成了“两层审批”，答辩时能清楚描述状态流转逻辑。

第二个改动是重新设计审批记录表。当前系统可能只有请假单表，没有专门存审批轨迹的表，这导致你无法回答“这条记录在谁手里待了多久”。建议新建一张approval_log表：

CREATE TABLE `approval_log` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `leave_id` INT(11) NOT NULL COMMENT '请假单ID', `approver_id` INT(11) NOT NULL COMMENT '审批人ID', `approval_level` INT(11) NOT NULL COMMENT '第几级审批', `action` TINYINT(4) NOT NULL COMMENT '操作：1通过 2驳回', `comment` VARCHAR(255) DEFAULT NULL COMMENT '审批意见', `create_time` DATETIME NOT NULL COMMENT '操作时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

改完这张表后，后台管理页面按请假单 ID 去查审批记录，就能展示一套时间线：发起申请 → 部门经理通过 → 总经理通过。这样代码量增加不大，但数据库设计深度明显不同，老师追问时你也能把“为什么加这张表、数据如何关联”说得足够具体。

从那以后，我每次拿到一套新源码，都会强制自己先导入 SQL、跑通登录、走完一条请假审批链路，再到 PDF 里核对功能清单，最后才动手改代码。这个顺序让我少走了很多弯道，希望帮到你。

本文还有配套的精品资源，点击获取