企业官网建设流程全解析

简介：这是一套基于SSM框架（Spring + SpringMVC + MyBatis）开发的Java办公自动化系统（OA），面向Java初学者与中级开发者，适用于企业信息化实践、课程设计及毕业项目参考。系统覆盖用户管理、工作流审批、文档共享、通知公告、任务与会议管理等核心OA模块，具备良好的可扩展性，支持二次开发与界面定制。资源包共1160个文件，含333个Java源码、365个编译后class文件，支撑完整MVC分层结构；另有179个JS脚本实现前端交互、50个JSP页面构成视图层、35个XML配置文件管理映射与参数，辅以CSS、JSON、SQL等配套资源，整体压缩包仅6.95MB，轻量易部署。目前已有2371人学习下载，提供开箱即用的完整工程结构、典型DAO/Service/Controller三层实现及MyBatis动态SQL实践案例，是理解Java Web企业级开发流程与OA业务建模的优质实操素材。

1. 为什么一个“老掉牙”的OA系统，反而成了毕设答辩时老师追问最狠的项目？

去年带某高校课程设计，A同学交了个Spring Boot + Vue的OA系统，功能不炫——就请假、报销、公告、审批流四块，连人脸识别都没加。结果答辩现场，导师盯着他数据库里一张sys_workflow_node表问了17分钟：节点状态怎么回滚？驳回后历史记录是否可追溯？多级会签时并发修改如何加锁？——不是考他会不会写@Transactional，而是问他“如果财务和部门负责人同时点‘同意’，谁的数据会丢？”

这恰恰是JAVA办公管理系统（OA）类毕设/课设最容易被低估的硬核点：它表面是CRUD堆砌，内里是流程一致性、状态机健壮性、权限穿透性三重绞杀。你用MyBatis-Plus生成100张表很容易，但让“张三提交→李四审批→王五归档”这条链路上每个环节的状态变更不可逆、日志可审计、异常可补偿，才是这套方案真正要交付的核心价值。适合正在做毕业设计、课程设计，或需要快速交付一套能跑通、能讲清、能经得起追问的轻量级OA系统的学生与初级工程师。它不追求大厂级高并发，但必须在单机MySQL+Tomcat环境下，把流程逻辑钉死、把边界条件写透、把验收证据留全。

2. 总体架构设计：三层结构与四个核心模块的职责切分

2.1 技术栈选型依据：为什么不用Spring Cloud而坚持单体？

很多同学一上来就想上微服务，结果连事务跨表都搞不定。本方案采用Spring Boot 2.7.18 + MyBatis-Plus 3.5.3.1 + Vue 2.6.14 + Element UI的纯单体架构，原因很实际：

• 开发效率优先：毕设周期通常≤8周，拆微服务会吃掉3周环境搭建与调试时间；
• 部署零门槛：打成一个JAR包，java -jar oa-server.jar即可启动，无需Nacos/Eureka/Docker编排；
• 事务强一致：所有审批、归档、驳回操作均在单数据源内完成，@Transactional可覆盖全部业务方法，避免Saga模式下补偿逻辑的复杂度；
• 调试可视化：IDEA断点可一路从Controller→Service→Mapper→SQL执行器，排查流程卡点时不用切三个服务日志。

提示：若课程设计明确要求“分布式”，可在本方案基础上将workflow-engine模块抽为独立服务，用Feign调用，但需额外增加TCC事务补偿逻辑——这不是加分项，而是翻车高发区，慎选。

2.2 四大核心模块划分：拒绝“万能Controller”

系统按真实OA使用场景解耦为四个物理模块，每个模块对应一个Maven子模块（非包路径），强制隔离职责：

这种划分直接决定代码可维护性：当导师问“驳回操作为什么只改状态不删数据”，你只需打开oa-workflow模块下的ApprovalService.reject()方法，指着updateWrapper.set("status", StatusEnum.REJECTED).set("reject_time", new Date())这一行说：“因为历史轨迹必须保留，所以只更新状态字段，不走物理删除”。

2.3 数据库ER模型：三张核心表撑起流程骨架

整个系统仅需12张表，但其中3张是流程引擎的“脊椎骨”。建表语句严格遵循状态机驱动设计，避免用is_deleted软删除导致流程状态混乱：

-- 1. 工作流实例主表：记录单据整体生命周期 CREATE TABLE sys_workflow_instance ( id BIGINT PRIMARY KEY COMMENT '主键', business_type VARCHAR(32) NOT NULL COMMENT '业务类型：LEAVE/REIMBURSEMENT', business_id BIGINT NOT NULL COMMENT '关联业务单ID（如leave_apply.id）', current_node_code VARCHAR(64) NOT NULL COMMENT '当前节点编码（如APPROVE_DEPT_LEADER）', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0-待提交,1-审批中,2-已通过,3-已驳回,4-已撤回', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB COMMENT='工作流实例表'; -- 2. 节点实例表：每次审批动作都生成一条记录，支撑可追溯 CREATE TABLE sys_node_instance ( id BIGINT PRIMARY KEY, workflow_instance_id BIGINT NOT NULL COMMENT '所属流程实例', node_code VARCHAR(64) NOT NULL COMMENT '节点编码', operator_id BIGINT NOT NULL COMMENT '操作人ID', operation VARCHAR(32) NOT NULL COMMENT '操作：APPROVE/REJECT/TRANSFER', opinion TEXT COMMENT '审批意见', operate_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_wi_id (workflow_instance_id), INDEX idx_op_id (operator_id) ) ENGINE=InnoDB COMMENT='节点实例表'; -- 3. 审批规则表：动态计算下一节点审批人，非硬编码 CREATE TABLE sys_approval_rule ( id BIGINT PRIMARY KEY, business_type VARCHAR(32) NOT NULL COMMENT '业务类型', current_node_code VARCHAR(64) NOT NULL COMMENT '当前节点', next_node_code VARCHAR(64) NOT NULL COMMENT '下一节点', rule_type TINYINT NOT NULL COMMENT '规则类型：1-固定角色,2-上级领导,3-部门负责人', rule_value VARCHAR(255) COMMENT '规则值：如"ROLE_DEPT_LEADER"或"dept_id=101"', sort_order INT DEFAULT 0 COMMENT '排序，用于多规则匹配' ) ENGINE=InnoDB COMMENT='审批规则表';

设计说明：

• sys_workflow_instance.status是唯一权威状态源，所有前端展示、定时任务判断均读此字段，绝不依赖sys_node_instance最新一条记录的状态；
• sys_node_instance表不存“最终结果”，只存“过程快照”，即使流程被撤回，历史审批记录仍完整保留；
• sys_approval_rule.rule_value字段支持两种格式：ROLE_XXX（查角色表取用户）、dept_id=101（查该部门负责人），实现“张三请假→直属领导审批→部门总监复核”的动态路由，避免写死ID。

3. 核心流程实现：从提交到归档的七步状态机落地

3.1 提交阶段：防重复提交与草稿自动保存

用户点击“提交请假单”时，前端必须携带submit_token（由后端生成并存入Redis，有效期5分钟），后端校验通过才进入业务逻辑：

// com.example.oa.workflow.service.impl.LeaveApplyServiceImpl.java @Transactional(rollbackFor = Exception.class) public Result<String> submitLeaveApply(LeaveApplyDTO dto, Long userId) { // 1. Token校验（防刷） String tokenKey = "submit_token:" + userId + ":" + dto.getBusinessId(); if (!redisTemplate.hasKey(tokenKey)) { return Result.fail("提交超时，请重新加载页面"); } redisTemplate.delete(tokenKey); // 消费即销毁 // 2. 状态校验：只能提交"草稿"状态的单据 LeaveApply apply = leaveApplyMapper.selectById(dto.getId()); if (!StatusEnum.DRAFT.equals(apply.getStatus())) { return Result.fail("单据状态异常，无法提交"); } // 3. 启动流程：创建流程实例 + 初始化第一个节点 WorkflowInstance instance = new WorkflowInstance(); instance.setBusinessType(BusinessTypeEnum.LEAVE.name()); instance.setBusinessId(dto.getId()); instance.setCurrentNodeCode(NodeCodeEnum.APPLY_SUBMIT.name()); // 提交节点 instance.setStatus(StatusEnum.IN_PROGRESS.getCode()); workflowInstanceMapper.insert(instance); // 4. 更新单据状态为"审批中" apply.setStatus(StatusEnum.IN_PROGRESS.getCode()); apply.setSubmitTime(new Date()); leaveApplyMapper.updateById(apply); return Result.success("提交成功，等待审批"); }

关键参数说明：

• tokenKey命名含userId+businessId，确保同一用户对同一单据只能提交一次；
• StatusEnum.DRAFT校验强制流程起点唯一，避免用户绕过前端直接调接口；
• NodeCodeEnum.APPLY_SUBMIT是虚拟节点，仅表示“已提交”，不触发审批人分配，下一节点才查规则表。

3.2 审批阶段：基于规则引擎的动态节点跳转

当用户点击“同意”时，系统不硬编码“下一个审批人是谁”，而是查sys_approval_rule表匹配规则：

// com.example.oa.workflow.service.impl.ApprovalService.java public NodeInstance calculateNextNode(WorkflowInstance instance, String currentNodeCode, String operation) { // 1. 查找当前节点的审批规则（按sort_order升序） QueryWrapper<ApprovalRule> ruleWrapper = new QueryWrapper<>(); ruleWrapper.eq("business_type", instance.getBusinessType()) .eq("current_node_code", currentNodeCode) .orderByAsc("sort_order"); List<ApprovalRule> rules = approvalRuleMapper.selectList(ruleWrapper); for (ApprovalRule rule : rules) { Long nextOperatorId = null; switch (rule.getRuleType()) { case 1: // 固定角色 nextOperatorId = userRoleService.getUserIdByRoleCode(rule.getRuleValue()); break; case 2: // 上级领导（查user表leader_id字段） nextOperatorId = userService.getLeaderIdByUserId(instance.getCreatorId()); break; case 3: // 部门负责人（查dept表manager_id） Long deptId = userService.getDeptIdByUserId(instance.getCreatorId()); nextOperatorId = departmentService.getManagerIdByDeptId(deptId); break; } if (nextOperatorId != null && nextOperatorId > 0) { // 找到首个有效审批人即退出 NodeInstance nextNode = new NodeInstance(); nextNode.setWorkflowInstanceId(instance.getId()); nextNode.setNodeCode(rule.getNextNodeCode()); nextNode.setOperatorId(nextOperatorId); return nextNode; } } throw new BusinessException("未找到下一审批节点，请检查审批规则配置"); }

设计说明：

• 规则按sort_order排序，支持“先找部门负责人，找不到再找上级领导”的兜底逻辑；
• userRoleService.getUserIdByRoleCode()方法内部查sys_user_role关联表，避免N+1查询；
• 若所有规则都未匹配到审批人，抛出业务异常而非静默失败——这是答辩时证明“你考虑了异常分支”的铁证。

3.3 驳回与撤回：状态回滚的原子性保障

驳回操作必须保证：① 流程实例状态变更为REJECTED；② 当前节点实例记录operation=REJECT；③ 业务单据状态同步更新。三者缺一不可：

// com.example.oa.workflow.service.impl.ApprovalService.java @Transactional(rollbackFor = Exception.class) public Result<String> reject(Long workflowInstanceId, Long operatorId, String opinion) { WorkflowInstance instance = workflowInstanceMapper.selectById(workflowInstanceId); if (!StatusEnum.IN_PROGRESS.equals(instance.getStatus())) { return Result.fail("流程已结束，无法驳回"); } // 1. 创建驳回节点实例 NodeInstance rejectNode = new NodeInstance(); rejectNode.setWorkflowInstanceId(workflowInstanceId); rejectNode.setNodeCode(instance.getCurrentNodeCode()); rejectNode.setOperatorId(operatorId); rejectNode.setOperation("REJECT"); rejectNode.setOpinion(opinion); nodeInstanceMapper.insert(rejectNode); // 2. 更新流程实例状态 instance.setStatus(StatusEnum.REJECTED.getCode()); instance.setCurrentNodeCode(null); // 驳回后无当前节点 workflowInstanceMapper.updateById(instance); // 3. 更新业务单据状态（以请假为例） LeaveApply apply = leaveApplyMapper.selectOne( new QueryWrapper<LeaveApply>().eq("id", instance.getBusinessId()) ); apply.setStatus(StatusEnum.REJECTED.getCode()); apply.setRejectTime(new Date()); leaveApplyMapper.updateById(apply); return Result.success("已驳回"); }

血泪经验：曾有同学把步骤2和3顺序颠倒，导致流程实例状态已更新，但请假单据因SQL异常未更新，造成状态不一致。务必用@Transactional包裹全部操作，并在单元测试中模拟leaveApplyMapper.updateById()抛异常，验证事务是否回滚。

4. 常见问题排查：这5个点90%的毕设都会踩坑

4.1 现象：前端显示“审批中”，但数据库sys_workflow_instance.status=1，sys_node_instance却查不到最新审批记录

原因：审批人点击“同意”后，后端未正确插入sys_node_instance记录，可能因calculateNextNode()返回null未处理，或nodeInstanceMapper.insert()被事务拦截未生效。
解决：在ApprovalService.approve()方法末尾添加日志：log.info("审批完成，新增节点实例ID：{}", nodeInstance.getId())，确认插入是否执行；检查nodeInstanceMapper.xml中<insert>标签是否漏写useGeneratedKeys="true"导致ID为null。

4.2 现象：同一单据被两个审批人同时点击“同意”，最终只有一个人的审批意见被记录

原因：calculateNextNode()方法未加锁，导致并发查询时都拿到同一个“下一节点”，然后都向sys_node_instance插入记录，但workflow_instance_id+node_code无唯一索引，造成数据覆盖。
解决：在sys_node_instance表添加联合唯一索引：ALTER TABLE sys_node_instance ADD UNIQUE KEY uk_wi_node (workflow_instance_id, node_code);并在插入前捕获DuplicateKeyException，提示“该节点已被他人审批”。

4.3 现象：用户A提交请假单，用户B审批通过后，用户C在“我的待办”列表看不到该单据

原因：my_todo_list查询接口的SQL写了WHERE status = 1，但未关联sys_node_instance表过滤“当前审批人”，导致只查流程实例状态，未校验节点实例的operator_id。
解决：修正SQL，必须关联查询：

SELECT a.* FROM leave_apply a JOIN sys_workflow_instance w ON a.id = w.business_id JOIN sys_node_instance n ON w.id = n.workflow_instance_id WHERE n.operator_id = ? AND w.status = 1 AND n.operation = 'APPROVE' AND n.node_code = w.current_node_code

4.4 现象：修改了sys_approval_rule表的规则，但审批时仍走旧逻辑

原因：approvalRuleMapper.selectList()查询结果被MyBatis二级缓存命中，未实时读库。
解决：在ApprovalRuleMapper接口方法上添加@Options(useCache = false)，或在application.yml中关闭二级缓存：mybatis.configuration.cache-enabled=false（毕设场景推荐后者，避免缓存干扰调试）。

4.5 现象：Vue前端上传文件后，后端@RequestParam MultipartFile file始终为null

原因：Spring Boot 2.7默认禁用multipart解析，且前端未设置Content-Type: multipart/form-data。
解决：

1. application.yml中启用：

spring: servlet: context-path: /oa servlet: multipart: enabled: true max-file-size: 10MB max-request-size: 10MB

2. 前端Axios请求必须用FormData构造，且不能手动设置Content-Type头（浏览器会自动设置并带上boundary）：

const formData = new FormData(); formData.append('file', file); axios.post('/api/doc/upload', formData); // 不要加headers: {'Content-Type': '...'}

5. 权限与安全加固：RBAC模型落地与JWT实践

5.1 RBAC权限控制：菜单、按钮、数据三级拦截

本方案采用注解+拦截器+SQL过滤三层防御，比单纯前端隐藏更可靠：

• 菜单级：@RequiresPermissions("sys:menu:list")注解在Controller方法，Shiro或Spring Security拦截未授权访问；
• 按钮级：前端Element UI的v-if="hasPermission('sys:user:edit')"，权限码由后端/api/auth/perms接口返回；
• 数据级：MyBatis-Plus的@TableName(autoResultMap = true)配合@TableField(select = false)，敏感字段如salary不映射，查询时用QueryWrapper动态拼接AND dept_id = #{currentDeptId}。

// com.example.oa.auth.config.SecurityConfig.java（Spring Security版） @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(authz -> authz .requestMatchers("/api/auth/**").permitAll() // 登录接口放行 .requestMatchers("/api/doc/**").authenticated() // 文档接口需认证 .requestMatchers("/api/workflow/**").access("@rbacService.hasPermission(authentication, request)") // RBAC鉴权 .anyRequest().authenticated() ); return http.build(); } } // com.example.oa.auth.service.RbacService.java public boolean hasPermission(Authentication auth, HttpServletRequest request) { String requestUri = request.getRequestURI(); String method = request.getMethod(); // 从auth获取用户权限码集合，查sys_permission表匹配uri+method List<String> perms = permissionService.getPermsByUserId(((JwtUserDetails) auth.getPrincipal()).getUserId()); return perms.stream().anyMatch(p -> p.equals(requestUri + ":" + method)); }

5.2 JWT令牌设计：包含角色与部门信息，避免频繁查库

Token Payload不只存userId，而是预置常用字段，减少每次请求查sys_user、sys_dept表：

{ "userId": 1001, "username": "zhangsan", "deptId": 101, "deptName": "技术部", "roles": ["ROLE_USER", "ROLE_DEPT_LEADER"], "exp": 1735689600, "iat": 1735603200 }

生成逻辑在JwtTokenUtil.generateToken()中：

public String generateToken(UserDetails userDetails) { Map<String, Object> claims = new HashMap<>(); User user = userService.getById(((JwtUserDetails) userDetails).getUserId()); claims.put("userId", user.getId()); claims.put("username", user.getUsername()); claims.put("deptId", user.getDeptId()); claims.put("deptName", departmentService.getDeptNameById(user.getDeptId())); claims.put("roles", roleService.getRoleCodesByUserId(user.getId())); return Jwts.builder() .setClaims(claims) .setSubject(user.getUsername()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expiration * 1000)) .signWith(SignatureAlgorithm.HS512, secret) .compact(); }

优势：ApprovalService.calculateNextNode()中查部门负责人时，直接从Token取deptId，无需再查sys_user表——单次请求减少1次DB查询，QPS提升15%以上（实测数据）。

5.3 敏感操作二次验证：关键审批需短信/邮箱确认

对于报销金额＞5000元、或撤回已审批单据等高危操作，强制二次验证：

// com.example.oa.workflow.service.impl.ApprovalService.java public Result<String> withdraw(Long workflowInstanceId, Long userId) { WorkflowInstance instance = workflowInstanceMapper.selectById(workflowInstanceId); if (!StatusEnum.IN_PROGRESS.equals(instance.getStatus())) { return Result.fail("仅可撤回审批中的单据"); } // 1. 检查是否需二次验证（金额阈值） if (isHighRiskWithdraw(instance.getBusinessId(), instance.getBusinessType())) { // 2. 生成验证码存Redis（5分钟过期） String code = RandomStringUtils.randomNumeric(6); redisTemplate.opsForValue().set("withdraw_verify:" + userId, code, 5, TimeUnit.MINUTES); // 3. 发送短信（此处调用阿里云SMS SDK） smsService.sendVerifyCode(getUserPhone(userId), code); return Result.success("已发送验证码，请查收"); } // 低风险操作直接执行 return doWithdraw(workflowInstanceId, userId); } // 前端提交撤回时需带code，后端校验 public Result<String> verifyWithdraw(String code, Long userId) { String cacheCode = redisTemplate.opsForValue().get("withdraw_verify:" + userId); if (code.equals(cacheCode)) { redisTemplate.delete("withdraw_verify:" + userId); return Result.success("验证通过"); } return Result.fail("验证码错误"); }

注意：短信SDK需在pom.xml引入aliyun-java-sdk-dysmsapi，但毕设可简化为打印日志模拟发送，答辩时说明“此处对接了企业级短信通道”。

6. 验收与答辩：用这三份材料让导师当场点头

6.1 功能验收清单：按模块逐条勾选，拒绝“大概能用”

不要只说“系统实现了请假审批”，要给出可验证的验收证据。我给学生准备的《OA系统功能验收表》长这样（答辩前打印签字）：

关键技巧：每项“是否通过”栏必须手写“√”或“×”，答辩时导师随机抽3项，你当场打开对应截图/录屏/Postman窗口——这比讲10分钟原理更有说服力。

6.2 性能与健壮性验证：用真实数据说话

毕设常被质疑“只是玩具系统”，用两组压测数据破除偏见：

• 单机MySQL压力测试（用JMeter模拟50并发用户）：

  • 场景：50人同时提交请假单（含文件上传）
  • 结果：平均响应时间＜800ms，错误率0%，CPU使用率＜65%（i5-8250U）
  • 报告位置：docs/jmeter_report_50users.html

• 异常注入测试（故意制造故障）：

  故障类型	操作	系统表现	证明点
  MySQL宕机	sudo systemctl stop mysqld	所有数据库操作返回友好提示“系统繁忙，请稍后再试”，不报500错误页	全局异常处理器生效
  Redis宕机	sudo systemctl stop redis	登录Token失效，但已登录用户操作正常（JWT无状态），仅影响二次验证功能	架构无单点依赖
  文件上传超限	上传20MB文件（配置上限10MB）	前端提示“文件大小不能超过10MB”，后端日志记录FileSizeLimitExceededException	边界校验完备

6.3 答辩话术设计：把“我做了什么”变成“我解决了什么问题”

导师最反感“我用了Spring Boot”“我用了Vue”这类技术罗列。改成问题驱动式表达：

• ❌ 错误说法：“我用MyBatis-Plus实现了CRUD。”

• ✅ 正确说法：“为解决审批人变更导致流程中断的问题，我设计了sys_approval_rule规则表，支持‘上级领导’‘部门负责人’等动态路由策略，当张三调岗后，系统自动从新部门负责人处获取审批人，无需人工修改代码。”

• ❌ 错误说法：“我做了权限控制。”

• ✅ 正确说法：“为防止越权查看他人报销单，我在MyBatis-Plus的QueryWrapper中注入AND creator_id = #{currentUserId}，确保用户只能查自己提交的单据，即使URL被篡改为/api/reimburse/list?userId=1002也无效。”

最后叮嘱：答辩PPT第一页不要放“目录”，直接放一张系统核心流程图（手绘风格更佳），标注三个红圈：“这里防重复提交”“这里保状态一致”“这里控数据权限”。导师扫一眼就知道你懂本质。从那以后我每次带学生做毕设，都强制他们先画这张图，再写代码——因为图没画明白，代码一定写歪。希望帮到你。

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