企业官网建设流程全解析

JSP企业内部办公系统这个题目，看起来有点土，但每年毕业设计选题榜上从来没掉过前十，很多中小公司内部也还在维护着这类老系统。我帮人做过好几套同类项目，也当过评审看过不少学生交付的“办公系统”，有一句实在话放在前面：用两三个月从零做出一套能跑、能演示、能答辩的完整系统，JSP这套技术栈反而是最稳的选择——结构平铺直叙、排查链路短、和学校要求的SSH或MVC结构也能对上。

这篇文章就把“JSP企业内部办公系统的设计与实现”这条链路上的所有关键节点拆开讲：先讲清楚为什么选这个技术组合，再讲功能模块和数据库要怎么规划，然后从环境搭建一路讲到核心代码、打包部署，最后是一些交付和答辩时最容易翻车的细节。无论你是准备做毕设的学生，还是要给团队快速搭内部工具的技术负责人，都可以直接照着走。

1. 为什么2025年还会选JSP做办公系统：技术选型的冷思考

1.1 过时是真的，但存量市场也是真的

一说到JSP，很多人的第一反应是“这玩意早就过时了”。大厂招聘确实不怎么看JSP经验，新项目也基本不会从零选JSP，这事没有必要抬杠。但在高校毕设和小型企业内部系统这两个场景里，JSP的生命周期远没有结束。我见过太多学校还在用JSP+Servlet+MySQL讲Java Web，也见过好几个公司的OA或ERP系统是十年前用JSP开发的，至今每年还加需求、改bug。只要项目还在跑，就一定有维护者，也一定需要新人看懂它。

另一个现实是，对多数本科毕设和课程设计来说，技术新旧并不是决定性因素。评审老师关心的是：你是否真正理解了Web开发的请求-响应模型、Session会话管理、数据库操作和基本权限控制。这些基础概念用JSP能讲透，用Spring Boot反而容易被一堆注解和框架封装掩盖掉。换句话说，把JSP做明白的人，转Spring Boot只是时间问题；但直接拿Spring Boot写CRUD、连Servlet都没弄明白的人，工作里遇到问题往往很被动。

1.2 JSP办公系统的真实能力边界

办公系统的本质是大量结构化数据的增删改查，加上一部分审批流程。这类系统的特点是：并发不高、业务规则固定、界面要求不高、权限模型清晰。这正好落在JSP+Servlet的长处上。Servlet负责接收请求和控制跳转，JSP负责展示，JavaBean或DAO负责数据访问。只要严格分层，项目结构可以非常清楚，甚至比一些用了重框架的小项目还好读。

需要特别提醒的是，JSP不是让你在页面里写一堆<% %>脚本。很多人说JSP乱，其实是把页面写成了“带HTML的Java代码”。规范的做法是JSP里只做循环和判断展示，用EL表达式取数据，用JSTL标签控制输出，真正的前置处理全部放到Servlet里。这样分工之后，JSP页面里几乎看不到Java代码，维护难度和现在的模板引擎没有本质区别。做办公系统时如果能坚持这个原则，代码审查这一关就稳了一半。

1.3 和Spring Boot的真实差距

为了不被“过时”两个字带偏，我列了一张对比表。这个对比不捧谁不踩谁，只说明适用场景，方便你判断自己手里的项目到底该选哪条路。

如果你是抱着“三个月内完成一个能答辩的办公系统”的目标，选JSP没有任何问题。反过来，如果是给一个几十人的公司做未来五年的核心系统，那还是老老实实上Spring Boot。选型不是追新，是算清楚自己的时间成本和交付目标。

2. 先把功能地图画出来：模块、角色与权限矩阵

2.1 办公系统的必备模块

很多同学拿到题目第一件事就是建工程、配环境，结果做到一半发现功能东缺一块西缺一块。我习惯先把功能地图画出来，像做户型设计一样，先有总图再砌墙。

一个典型的企业内部办公系统，通常包含以下几块：

• 组织管理：部门维护、职位维护。部门要支持多级树形结构，因为公司一般有总部、中心、小组这种层级。
• 人事管理：员工信息增删改查、入职离职状态管理、员工调动。它是整个系统的基础数据源。
• 考勤管理：打卡记录、考勤统计。如果不想对接硬件打卡机，至少要做补卡申请、考勤异常申诉。
• 请假审批：请假、销假、加班申请。这是OA类系统的核心流程，必须有表单提交、列表审批、状态流转。
• 公告通知：发布公告、查看公告、置顶、下线。这是企业里使用频率最高的模块，也是演示时最好展示的模块。
• 文档管理：上传文件、下载文件、按部门设置可见范围。需要处理文件存储路径和权限控制。
• 系统管理：用户管理、角色管理、菜单管理、操作日志。这部分是权限控制的基础，不能省。

每个模块对应的页面数大概在2到3个，比如请假模块就至少需要“发起请假页”“我的请假列表页”“审批列表页”三个页面。把所有模块过一遍，整个系统的页面量通常在15到25个之间，这对一个两三个月的项目来说工作量是合理的。

2.2 三类角色与权限边界

办公系统里权限不能只分“管理员”和“普通用户”，太粗了。按最常见的公司结构，至少要划分出三种角色：

这里有个容易忽略的点是“数据权限”，也就是部门经理能看到的数据范围。普通员工只能看自己，经理能看本部门，管理员能看全部。这种水平方向的数据隔离，如果不单独处理，很多初学者会把权限做成“只要能登录，所有列表都看得见”，那样系统从业务角度就是不成立的。

2.3 模块拆分对开发的影响

功能模块定得越细，数据库表和代码包结构就越好设计。我一般会把模块直接映射到代码包的component，比如controller/leave、controller/attendance，每个模块一个Servlet或一个Controller类，页面也按模块放到独立目录下。模块边界清楚之后，两个人协作开发时几乎不会冲突，一个人负责考勤，一个人负责审批，各改各的包。

另外要提醒的是，办公系统很容易贪大。今天想加一个在线聊天，明天想加一个工资条，后天想加一个会议管理。作为交付目标是赶不过来的。先做“员工管理+考勤+请假审批+公告+权限”的闭环，把审批流程跑通，剩下全是加分项。闭环的意思是：公司有一个新人从入职、请假、被审批、发工资、领公告通知，能在系统里完整走一遍。

3. 数据库模型：核心表结构、外键关系与权限落地

3.1 用户、角色、菜单三张主表

办公系统的权限我强烈推荐直接用RBAC模型，也就是用户-角色-菜单。用户表不直接存一堆权限标记，而是挂一个角色；角色再去关联一组菜单；菜单表里存每个功能页面的URL。

用户表和角色表、部门表的关系大概是这样的：

CREATE TABLE sys_user ( user_id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, salt VARCHAR(32) NOT NULL, real_name VARCHAR(50) NOT NULL, dept_id INT, role_id INT, phone VARCHAR(20), email VARCHAR(100), hire_date DATE, status TINYINT DEFAULT 1 COMMENT '1在职 0离职', create_time DATETIME, KEY idx_dept (dept_id), KEY idx_role (role_id) );

角色表和菜单表相对简单：

CREATE TABLE sys_role ( role_id INT AUTO_INCREMENT PRIMARY KEY, role_name VARCHAR(50) NOT NULL, role_key VARCHAR(50) NOT NULL UNIQUE, description VARCHAR(255) ); CREATE TABLE sys_menu ( menu_id INT AUTO_INCREMENT PRIMARY KEY, parent_id INT DEFAULT 0, menu_name VARCHAR(50) NOT NULL, url VARCHAR(200), menu_type TINYINT DEFAULT 1 COMMENT '1菜单 2按钮', icon VARCHAR(50), sort_no INT DEFAULT 0 ); CREATE TABLE sys_role_menu ( role_id INT NOT NULL, menu_id INT NOT NULL, PRIMARY KEY (role_id, menu_id) );

这里有几个容易踩的坑。第一，密码字段不要设成纯MD5之后就不管了，一定要加随机盐，否则两个人密码相同加密结果也一样，一看就是纯MD5。第二，menu_type要区分菜单和按钮，菜单控制的是“能进哪个页面”，按钮控制的是“页面上能不能看到新增、删除、审批”这些操作，评审老师如果问权限细化到哪一层，这两张表分开设计就是亮点。第三，外键和索引要加上，但不要滥用级联删除，比如删除部门时直接把部门下所有员工一并删掉，实际业务里更合理的做法是把员工挂到“未分配部门”，或者提示先调整员工归属。

3.2 业务表的设计要点

业务表围绕具体功能展开。请假审批表是权限之外最重要的表，字段要能完整还原一次审批过程：

CREATE TABLE oa_leave ( leave_id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, leave_type VARCHAR(20) NOT NULL COMMENT '事假/病假/年假/调休', start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, leave_days DECIMAL(5,1) NOT NULL, reason VARCHAR(500), status TINYINT DEFAULT 0 COMMENT '0待审批 1通过 2驳回 3已撤销', apply_time DATETIME NOT NULL, approver_id INT, approve_time DATETIME, approve_comment VARCHAR(500), KEY idx_user (user_id), KEY idx_status (status) );

考勤表建议一天一人一条记录，用打卡日期做唯一约束，这样可以避免重复打卡生成多条脏数据。公告表要区分发布状态和置顶状态，过期的公告可以自动下线，不必物理删除。文档表则要存文件原始名称和存储路径，上传文件时Servlet需要处理multipart/form-data，用commons-fileupload组件最省事。

还有一个很多人忽略的“操作日志表”。哪怕只记录最关键的登录时间、IP、用户ID，就能显著提升项目的完整度。答辩时老师问“系统有没有审计功能”，你直接打开日志页当场演示，效果比解释一百句都好。

3.3 演示数据怎么造才像一个真实公司

数据库设计完成后，造演示数据是非常讲究的一步。很多人的演示数据是 admin、admin123、张三、李四这样的随便填，看起来非常假。我的做法是造一套有业务逻辑的完整数据：

• 两个部门：技术部和人事部。
• 十来个员工，名字要有真实感，手机号、邮箱、入职时间、职位都能对上。
• 至少一条完整的请假审批链：技术部员工“王伟”发起三天年假，技术部经理“刘洋”审批通过。
• 考勤数据要包含正常打卡、迟到、缺卡各几笔，方便演示统计。

这样造数据的好处是，你演示时跳过任何一个页面，数据都是连贯的。老师随便点进一个员工页面，点进去能看见请假记录、考勤记录，而不是全是空表。视觉上“系统被真正使用过”这件事，对印象分的提升非常明显。

4. 环境搭建与项目骨架：JDK、Tomcat、Maven、IDEA逐个对齐

4.1 版本组合怎么选最不容易出问题

JSP项目最怕的就是版本错配，一个不兼容能折腾一整天。我的建议是不要追新，直接用已经被验证过的稳定组合：

• JDK 1.8，不要用17或21。虽然新JDK也能跑Tomcat，但Tomcat版本、编译插件、IDE的一些兼容性坑会无缘无故冒出来。
• Tomcat 9.0，对应Servlet 4.0规范，兼容性最好。
• MySQL 5.7或8.0，驱动用对应的Connector/J 8.x。
• IDEA 2022以上版本。
• Maven 3.6.3以上，用来管理依赖和打war包。

数据库这里要特别注意，MySQL 8默认使用caching_sha2_password认证，如果驱动版本太旧会报连接失败，所以Java程序连接时最好用com.mysql.cj.jdbc.Driver，连接串里明确带上useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8。这三段缺一个，晚上十点还在群里问“为什么连不上数据库”的人就是你。

4.2 从IDEA新建Maven war工程到第一行代码

创建项目的步骤不复杂，但每一步都有细节：

1. IDEA里选 New Project，左侧选 Maven，不要选自带Web骨架的模板，那个模板比较旧。在pom.xml里手动把打包方式改成war。
2. 在src/main下补一个webapp/WEB-INF/web.xml，IDEA如果没生成就自己建。
3. 在pom.xml里加依赖，最基础的四件套是Servlet API、JSTL、MySQL驱动、数据库连接池。

pom.xml里我习惯这么配：

<dependencies> <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> <dependency> <groupId>c3p0</groupId> <artifactId>c3p0</artifactId> <version>0.9.5.5</version> </dependency> </dependencies>

Servlet API的scope一定要是provided，因为Tomcat里已经内置了Servlet实现。如果写成compile，打war包时会把Servlet的类也打进去，部署后容易出现各种诡异的类冲突。连接池我推荐c3p0或HikariCP，前者学校资料多，后者性能更好，学生项目用c3p0就行。

目录结构建议按包分层，一个典型的包名是com.company.oa，下面分controller、service、dao、entity、util、filter。JSP页面统一放到webapp/WEB-INF/jsp下面，好处是外部浏览器不能直接通过URL访问JSP文件，所有页面都必须经过Servlet转发，安全性也好，页面目录也不会乱。

4.3 编码问题提前干掉

中文乱码是JSP项目里最常见、也最让人无语的问题。其实只要把四个地方统一成UTF-8，基本不会再乱：

1. JSP页面头部contentType="text/html; charset=UTF-8"。
2. IDEA的Settings里把Global Encoding、Project Encoding、Properties Files Encoding都设为UTF-8。
3. 数据库连接串里加characterEncoding=utf8。
4. Tomcat的server.xml里给Connector加一行URIEncoding="UTF-8"。

另外，如果用了MySQL 8，连接串里的serverTimezone必须指定，否则启动时大概率报时区错误。我习惯统一写Asia/Shanghai，不要写UTC，否则存进数据库的时间和北京时间差八小时，查日志时很伤脑筋。

5. 核心代码链路：登录、会话、权限拦截与公共DAO

5.1 登录逻辑和密码存储

登录是整个系统的入口，代码顺序要清晰：先做参数校验，再查用户，再验密码，然后把用户信息放进Session，最后跳转。

密码处理这块，直接用裸MD5已经不够看了。我一般是这样做的：注册或初始化用户时生成一个随机salt，密码存MD5(明文密码 + salt)的结果。验证的时候把用户输入的内容拼接该用户的salt，再算一次MD5做比对。这样做的好处是即使两个用户密码一样，数据库里的密文也不一样。

关键代码如下，模式很简单：

public class Md5Util { public static String getSalt() { return UUID.randomUUID().toString().replace("-", "").substring(0, 16); } public static String encrypt(String password, String salt) { String base = password + "#" + salt; return DigestUtils.md5Hex(base); } }

登录成功之后，Session里至少要存三个信息：用户ID、用户名、角色标识。不要整个User对象都塞进Session，也没必要。但角色标识必须放，后面Filter做权限拦截要用。

5.2 用Filter统一做登录校验和权限拦截

一个企业内部办公系统，除了登录页和静态资源，其余请求都应该经过登录校验。用Filter做一个全局拦截，是最简单且不容易遗漏的做法：

public class AuthFilter implements Filter { @Override 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.jsp") || uri.contains("/login") || uri.contains("/static/") || uri.contains("/assets/")) { chain.doFilter(req, resp); return; } HttpSession session = request.getSession(); if (session.getAttribute("loginUser") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(req, resp); } }

Filter里有两个坑提前说。第一个是放行静态资源，如果你用了CSS、JS、图片，不放行就得写一堆web.xml的servlet-mapping，最后页面还丑得不行。第二个是Ajax请求被Filter挡了之后，浏览器端收到的其实是302重定向，前端判断会很别扭，所以Ajax请求要么在服务端返回一个{"code":401}的JSON，要么前端在全局Ajax里统一捕获登录过期逻辑。这个细节很多项目不做，但实际部署后用户点着点着就跳出个黑屏报错页面，体验很差。

5.3 DAO层、连接池和公共查询模板

办公系统90%的代码是数据库增删改查。不要每个Servlet里直接写JDBC，那样每段数据库代码都得重复加载驱动、拿连接、关闭资源，代码丑到没法维护。正确做法是做一个DBUtil负责拿连接，再做一个BaseDAO把通用的查询和更新封装起来。

DBUtil核心就是注册驱动和从c3p0连接池拿连接：

public class DBUtil { private static ComboPooledDataSource dataSource; static { try { dataSource = new ComboPooledDataSource(); dataSource.setDriverClass("com.mysql.cj.jdbc.Driver"); dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/oa_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8"); dataSource.setUser("root"); dataSource.setPassword("123456"); } catch (Exception e) { throw new RuntimeException("初始化数据库连接池失败", e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } }

BaseDAO里封装两个方法就够了，一个是查询列表返回Map或实体，一个是执行更新。查询方法里传一个String sql和Object[] params，内部用PreparedStatement防止SQL注入。如果每张表都写一个完整的查询方法，代码量会爆炸，而且表一多就全是复制粘贴。

5.4 JSP页面怎么组织才能少写重复代码

JSP页面最大的问题是重复的导航栏和页脚。每个页面都复制一份导航代码，改一个菜单就得全站修改。更好的做法是公共部分拆成单独的文件，用<%@ include %>或JSTL导入。另外，所有JSP页面放在WEB-INF下之后，页面跳转必须用Servlet的request.getRequestDispatcher("/WEB-INF/jsp/xxx.jsp")，超链接和表单提交都指向Servlet，这样页面结构才统一。

按钮级的权限控制在JSP里通常用JSTL的c:if判断。比如审批按钮，只有当当前用户是部门经理且请假单状态为待审批时才对所有人可见。变量在Servlet里放到request域，页面里直接取。这样做的好处是权限判断集中在服务端，页面只负责展示，逻辑不会被绕过。

6. 调试、打包与部署：本地跑通不等于服务器跑通

6.1 常见运行时问题先打预防针

JSP项目本地跑通了，换到另一个环境就挂掉，这种事我见得太多了。先列一张常见问题排查表，省得到时候抓瞎：

其中文件路径这个问题最容易忽视。开发时你可能把上传文件存在项目目录下，但项目部署时tomcat会解压war包到临时目录，文件一旦被上传到里面的临时路径，服务器重启后文件目录被清空，所有上传文档瞬间消失。正确的做法是把文件存储目录配置成一个与项目无关的外部绝对路径，数据库里只存这个路径下的相对路径。

6.2 手动打包war与Tomcat部署步骤

本地调试完，交付前一定要打一次war包，并且在一台干净环境里完整走一遍部署流程。Maven项目打war包很简单：

mvn clean package

执行完后target目录下会生成xxx.war。这个war包可以直接复制到Tomcat的webapps目录下，启动Tomcat后会自动解压部署。数据库导入用命令行最稳：

mysql -u root -p -e "CREATE DATABASE oa_db CHARACTER SET utf8mb4;" mysql -u root -p oa_db < oa_db.sql

部署前要修改数据库连接配置里的密码。如果你把数据库密码写死在DBUtil的代码里，打war之前改一次源码重新编译；如果项目用了properties文件，直接改war包里的配置文件重启即可。我更推荐后一种，因为给客户或老师演示时，往往需要让对方改自己的数据库密码，properties文件改起来不需要重编译。

6.3 部署后仍会翻车的几个隐蔽点

第一次部署成功后，建议按这个顺序做体检：

1. 先访问首页和登录页，确认静态资源正常加载，样式没乱。
2. 登录一个普通员工账号，确认菜单只显示该角色该看到的模块。
3. 走一遍请假审批流程，看状态流转是否正确，审批记录是否写入。
4. 上传一份文档，然后重启Tomcat，再打开下载，确认文件还在。
5. 查一下日志文件有没有异常信息，数据库连接池有没有自动回收连接。

时区和时间问题也经常在部署后出现。如果你用的服务器时间不对，所有考勤记录、审批时间都会错位。Linux上要执行date -R看时区，不对就先改时区再同步时间。另外MySQL的sql_mode如果比较严格，有些写法在本地5.7能跑、服务器8.0直接报错，所以本地和线上数据库版本尽量保持一致。

7. 交付与答辩：决定分数的往往不是技术而是细节

7.1 一套完整的交付物应该长什么样

很多人把系统做出来就以为完事了，最后分数不高其实怨不了技术。交付物是一个完整闭环，至少包含以下五样：

数据库设计文档是很多人忽略的。作为技术方案，不需要很长，但至少每个表要有表名、用途、关键字段说明，特别是权限相关的表关系要画清楚。老师翻开文档看到这些，比你答辩时嘴说十句都管用。

7.2 演示数据与演示流程的排练技巧

演示是整个交付过程中最容易失分的地方。我见过有人演示时卡在登录页，因为数据库没启动；也见过演示到一半发现审批列表里空空如也，因为演示数据造得少。这里分享一个固定套路，照着走基本不会出错：

整个演示流程控制在三到五分钟，按一条完整业务故事线走：管理员用admin登录，进入系统管理，看到角色和权限设置；切换到普通员工账号，发起请假申请；切到部门经理账号，审批通过；回到员工账号，看到审批通过的考勤和公告。这条线把权限、审批、数据隔离都演示到了，节奏紧凑。

演示前要做两次预演。第一次自己单独走一遍，把可能出现的报错记下来；第二次找同学或同事当观众，练一下讲解节奏。还要准备好一个“兜底方案”：数据库服务、Tomcat服务全部提前启动好，演示用的浏览器清掉缓存，连不上时有一个备用账号和备用网络。这些细节决定不了你是不是天才，但决定你现场是不是流畅。

7.3 我做完几套这种系统之后的一些体会

这套系统做了几遍之后，我最大的感受是：JSP能不能做出好项目，不取决于框架新旧，取决于你愿不愿意把分层、权限、日志、异常处理这些基本功做扎实。很多差评项目并不是因为用了JSP，而是因为Servlet里塞了一千行SQL、JSP页面里混着几百行脚本、数据库密码裸写在源码里，这些毛病换任何框架都一样会挂。

如果你按这套思路把项目做完，你会发现它不仅是一个能得分的毕设，还是一个能拿出手的“工作量证明”。后续想转Spring Boot，你会很清楚MVC到底在做什么、Filter和Interceptor有什么区别、连接池为什么会提高性能，这些都是写简历和面试时要用的硬通货。最后提醒一句：答辩前一天记得把源码格式化、把每个类加上必要注释、把数据库脚本重新导一遍，确定能从零恢复到能跑的状态，这比任何花哨的技巧都管用。