Java OA系统源码包实战：从SSM到Spring Boot的部署与二次开发

简介一份面向Java开发者的企业办公OA系统实战资源围绕Spring Boot/Spring MVC、MyBatis等主流技术栈展现从数据库设计到前后端联调的企业级项目完整链路适合初学者进阶或应届生准备项目经验时参考。资源包共4个文件含2个讲解视频mp4、1个完整源代码压缩包zip和1个SQL数据库脚本总计206.01MB。视频细致讲解了系统架构、核心模块实现、数据库设计以及代码运行调试方法源代码覆盖工作流管理、文档管理、任务分配、公告通知等OA高频功能SQL脚本附带示例数据导入后即可快速启动项目。当前已有312人学习下载通过对照视频研读源码能深入理解Java企业级应用的分层结构、权限控制与数据交互思路为后续二次开发或独立搭建类似系统提供参考。1. 为什么一套“Java OA系统”源码包比你自己从零搭更值得花时间企业办公OA系统说白了就是把“申请-审批-通知”这条业务链搬上线。你拿到手的这套基于Java的企业办公OA系统资源包里面是源代码、讲解视频和数据库脚本三件套解决的不是“会不会写Java”的问题而是“一套能跑、能改、能演示的完整业务闭环从哪来”的问题。很多人在公司做内部项目或被面试官问起项目经验时最缺的恰恰不是零散的技术点而是一个拿得出手的完整系统。这个资源包典型的适用场景有三类一是刚学完SSM或Spring Boot的初学者需要一个真实项目把框架、数据库、前端串起来二是做课程设计或毕业设计的在校生需要一个能演示、能讲清楚业务逻辑的底座三是准备Java面试的开发者需要用OA系统的审批流、权限模型去回答“你做过什么项目”这类问题。它的核心价值在于把散落的Java基础、框架用法和数据库设计整合成了一个具体业务载体而不是让你对着语法书空转。这套方案里最值得关注的不是代码量而是里面封装的OA系统通用套路用户、角色、菜单权限怎么设计审批流程的状态怎么流转待办已办如何关联这些才是换任何公司都不过时的底子。拿到包之后别急着跑先把架构摸清楚后面改起来才不翻车。2. 先把技术底座拆清楚这套OA系统的架构、技术栈与跑通最小姿势2.1 SSM 还是 Spring Boot先从代码结构判断这套 OA 的出身拿到源码包后第一件事不是点开视频而是解压后看目录结构。常见做法是早期OA系统多采用SSM框架也就是Spring Spring MVC MyBatis的组合出厂结构通常是src/main/java下分controller、service、mapper、entity四层配applicationContext.xml、spring-mvc.xml、mybatis-config.xml等XML配置文件。而较新的版本会直接上Spring Boot目录里只有一个启动类配置集中在application.yml里。判断方法很简单# 解压后先看根目录 unzip OA系统.zip -d OA系统 cd OA系统 # 存在 pom.xml 且内容里有 spring-boot-starter-parent 就是 Spring Boot grep -i spring-boot-starter-parent pom.xml # 存在大量 applicationContext-*.xml 则是传统 SSM ls src/main/resources/*.xml我在本地跑这样的项目时通常会先看一眼pom.xml里依赖的版本号。Spring Boot 2.x 和 3.x 的起手式差别很大2.x 用javax.servlet3.x 强制jakarta.servletJDK 也至少要 17。如果你的本机是 JDK 8拿到 Spring Boot 3.x 的项目会直接编译失败这时候要么换 JDK要么先看有没有兼容分支。2.2 跑起来的最小配置清单JDK、MySQL、Tomcat和三个必改参数不管哪种架构跑通这套OA系统都需要先准备好运行环境。这里按最小可行配置给出一份清单新手照这个来不会出大错组件版本建议说明JDK1.8SSM项目或 17Spring Boot 3.x版本不对是编译期最常见的坑MySQL5.7 或 8.05.7 用com.mysql.jdbc.Driver8.0 用com.mysql.cj.jdbc.DriverTomcat8.5SSM 项目用Spring Boot 自带内嵌 Tomcat无需单独装Maven3.6用于拉取依赖配阿里云镜像速度更快数据库导入是最关键的一步。资源包里的.sql文件通常有两类一类是带CREATE DATABASE的完整初始化脚本一类只是建表语句。导入命令如下mysql -u root -p -e CREATE DATABASE IF NOT EXISTS oa_system DEFAULT CHARACTER SET utf8mb4; mysql -u root -p oa_system 数据库脚本.sql导入后一定要改数据库连接配置。SSM项目去改jdbc.propertiesSpring Boot 项目改application.yml# jdbc.properties 传统写法 jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/oa_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password你的密码# application.yml Spring Boot 写法 spring: datasource: url: jdbc:mysql://localhost:3306/oa_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver这里有两个参数特别提醒。一个是serverTimezoneAsia/ShanghaiMySQL 8.0 没这个参数会报时区错误另一个是characterEncodingutf8不设的话中文会乱码。很多新手跑不起来OA系统八成是卡在这两个小参数上而不是业务代码里。配置改完后SSM项目打 war 包丢进 Tomcat 的webapps目录Spring Boot 项目直接mvn spring-boot:run。启动日志里看到Tomcat started on port(s): 8080就说明跑通了浏览器访问http://localhost:8080/项目名/就能看到登录页。2.3 初始账号和菜单入口登录进去先别乱点按这条路径验证系统跑起来后用资源包说明里的初始账号登录。常见做法是管理员账号admin/admin123普通员工账号可能是user/123456。登录后按这个顺序点一遍基本能把系统的核心功能摸透个人办公发一条内部通知看是否出现在待办列表审批流程提交一份请假申请用管理员账号登录去审批看状态是否从“待审批”变成“已通过”系统管理打开用户管理看角色和菜单权限是否按预期控制如果这三个环节都能走通说明数据库脚本和代码版本是匹配的。这里最怕的是源码包和数据库脚本版本对不上——表里缺字段、代码里查不到列这类问题后文会专门讲排查方法。初始账号确认可以登录后才开始进入真正的学习环节把代码和数据库表结构对照着看效率远比从头看视频高。3. 数据库设计的核心一套OA系统是怎么用几十张表撑起审批流的3.1 八大核心表拆解人员、组织、权限和流程的四层结构OA系统的数据库设计有很强的通用性。不管外包公司做的还是SaaS产品核心表的结构八九不离十。这套资源包里的数据库脚本通常会包含以下这些关键表部门表sys_dept、用户表sys_user、角色表sys_role、菜单权限表sys_menu、用户角色关联表sys_user_role、角色菜单关联表sys_role_menu再加上业务表如请假申请表oa_leave和审批记录表oa_audit_record。这组表的设计思路是典型的RBAC模型——用户归属部门、用户绑定角色、角色关联菜单权限。业务上请假单提交后写入oa_leave审批人在oa_audit_record里追加一条记录同时更新oa_leave的status字段。整个审批流不依赖第三方工作流引擎时就是靠这两个表撑起来的。-- 用户表核心字段简化版 CREATE TABLE sys_user ( user_id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 用户ID, dept_id bigint(20) DEFAULT NULL COMMENT 部门ID, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT 密码(MD5加密), real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, email varchar(100) DEFAULT NULL COMMENT 邮箱, status char(1) DEFAULT 0 COMMENT 状态 0正常 1停用, PRIMARY KEY (user_id), KEY idx_dept_id (dept_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这张表里dept_id建立了和部门表的关联status字段比直接物理删除更稳妥这是企业系统的通用做法。密码字段用MD5只是初版方案如果你要在此基础上做二次开发建议改成BCrypt加密MD5在现今的环境下太容易撞库了。3.2 审批流的两张关键表状态字段和审批记录怎么配合审批流的灵魂不在oa_leave表而在oa_audit_record表。很多人在自己写OA系统时只想到用一个status字段标记当前状态结果审批历史和审批人信息全丢了。这套方案里用独立审批记录表每经过一个审批节点就插一条数据才能支持“审批进度可追溯”这个硬需求。-- 请假申请表业务主表 CREATE TABLE oa_leave ( leave_id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 申请人, leave_type varchar(20) DEFAULT 事假 COMMENT 请假类型, start_time datetime DEFAULT NULL, end_time datetime DEFAULT NULL, reason varchar(500) DEFAULT NULL, status tinyint(4) DEFAULT 0 COMMENT 0待审批 1已通过 2已驳回, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (leave_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 审批记录表流程日志 CREATE TABLE oa_audit_record ( record_id bigint(20) NOT NULL AUTO_INCREMENT, business_type varchar(30) NOT NULL COMMENT 业务类型 leave/expense等, business_id bigint(20) NOT NULL COMMENT 业务主键ID, audit_user_id bigint(20) NOT NULL COMMENT 审批人, audit_status tinyint(4) DEFAULT NULL COMMENT 1通过 2驳回, comment varchar(500) DEFAULT NULL COMMENT 审批意见, audit_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (record_id), KEY idx_business (business_type,business_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT审批记录表;这套设计的关键在于business_typebusiness_id的组合。请假、报销、用章申请都往oa_audit_record里写不用为每种业务建一套审批记录表扩展新业务时只加business_type的值就行。如果你后续想在OA系统里加一个“会议室预约”模块直接复用这套结构不需要动审批逻辑的代码。3.3 写一个联合查询从用户到菜单权限的完整链路搞清楚了表结构就能理解登录后左侧菜单为什么是“千人千面”。用户登录时系统按“用户→角色→菜单”这条链路去查权限-- 查询某个用户的菜单权限去重后按排序字段排列 SELECT DISTINCT m.menu_id, m.menu_name, m.url, m.perms, m.parent_id, m.order_num FROM sys_user u INNER JOIN sys_user_role ur ON u.user_id ur.user_id INNER JOIN sys_role r ON ur.role_id r.role_id INNER JOIN sys_role_menu rm ON r.role_id rm.role_id INNER JOIN sys_menu m ON rm.menu_id m.menu_id WHERE u.user_id 1 AND m.status 0 ORDER BY m.order_num ASC;这个查询的关键在DISTINCT关键字——一个用户可能会被赋予多个角色角色之间菜单有交叉时不加DISTINCT就会出现重复菜单。面试时被问到“权限设计怎么做”把这条SQL连同RBAC模型讲清楚比背概念有用得多。实际项目中还会加一层数据权限比如部门经理只能看到本部门的申请单那就要再关联sys_dept做数据过滤这套基础表结构是能支撑这种扩展的。4. 代码层面的三条主线路登录、权限拦截与审批状态流转4.1 登录验证和Session管理从Controller到Interceptor的调用链登录是每个系统都有的功能但OA系统里登录逻辑有一个独特之处登录成功后的用户对象要同时存Session和ThreadLocal前者给页面展示用后者给Service层拿当前操作人用。这套资源包里的代码Controller层通常是这么写的Controller RequestMapping(/login) public class LoginController { Autowired private SysUserService sysUserService; PostMapping(/doLogin) public String doLogin(String username, String password, HttpSession session, Model model) { SysUser user sysUserService.login(username, password); if (user null) { model.addAttribute(error, 用户名或密码错误); return login; } // 登录成功后写入 Session session.setAttribute(loginUser, user); // 把当前用户放到 ThreadLocal 供 Service 层使用 UserContext.set(user); return redirect:/index; } }这里有一个重要的设计细节UserContext.set(user)。OA系统里很多业务操作不需要前端把“当前是谁”传过来比如提交请假单时要在oa_leave.user_id里写入申请人。如果不做ThreadLocal每个Service方法都要从Session里取值再传参代码会非常啰嗦。用UserContext这个静态工具类Service层随时可以拿当前用户。登录之后就是拦截器的工作。传统SSM项目在spring-mvc.xml里配置拦截器Spring Boot项目则用WebMvcConfigurer注册public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); Object loginUser session.getAttribute(loginUser); if (loginUser null) { // AJAX 请求返回 JSON页面跳转请求重定向到登录页 String requestedWith request.getHeader(X-Requested-With); if (XMLHttpRequest.equals(requestedWith)) { response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\登录超时\}); } else { response.sendRedirect(request.getContextPath() /login); } return false; } return true; } }拦截器里区分AJAX和普通请求这是OA系统开发里的一个典型边界问题。不区分的话用户会话超时后点页面里的“审批”按钮结果整页被跳到登录页体验很差如果只是前端框架拿到一个HTML响应更是莫名奇妙。返回JSON状态码让前端统一处理跳转才是企业系统的做法。看到这里你会发现登录这块牵扯到Session生命周期管理、拦截器注册路径匹配、AJAX特殊处理三个知识点这套源码包里的实现值得一行行跟读。4.2 审批状态流转的核心Service状态机不再是玄学OA系统的审批功能本质是一个轻量级状态机待审批 → 通过/驳回驳回后可以重新提交回到待审批。不需要引入Activiti这类重量级工作流引擎时状态流转的Service方法可以写得很清楚Service public class LeaveServiceImpl implements LeaveService { Autowired private LeaveMapper leaveMapper; Autowired private AuditRecordMapper auditRecordMapper; Transactional(rollbackFor Exception.class) public void audit(Long leaveId, Integer auditStatus, String comment) { // 1. 查出当前请假单校验状态是否为“待审批” OaLeave leave leaveMapper.selectById(leaveId); if (leave null || leave.getStatus() ! 0) { throw new BusinessException(该申请单不存在或已被处理); } // 2. 更新主表状态1通过 2驳回 leave.setStatus(auditStatus); leaveMapper.updateById(leave); // 3. 写入审批记录 OaAuditRecord record new OaAuditRecord(); record.setBusinessType(leave); record.setBusinessId(leaveId); record.setAuditUserId(UserContext.getUserId()); record.setAuditStatus(auditStatus); record.setComment(comment); auditRecordMapper.insert(record); } }这段代码是OA系统里最值得背下来的模式先校验再更新、业务操作与日志记录放在同一事务、通过UserContext拿当前操作人。Transactional注解保证updateById和insert要么都成功要么都回滚避免出现主表状态改成了“已通过”但审批记录没写进去的数据不一致问题。状态流转的编码原则就是“永远不要在Service里散落一堆status 1的魔法值”。这套代码里如果用了常量类或枚举来定义状态你就照着用如果是裸数字二次开发时应重构掉。否则一个项目做完代码里10处status 1没人知道哪个“1”代表什么状态。4.3 前端页面的异步刷新待办列表消失的瞬间发生了什么OA系统业务页面有一个高频交互审批人在待办列表点击“通过”按钮后这一条就应从待办消失转移到已办列表。这套系统的前端通常用jQuery Layui或Bootstrap实现核心逻辑是提交后刷新表格数据// 审批通过/驳回操作 function doAudit(leaveId, auditStatus) { var comment $(#comment).val(); if (!comment) { layer.msg(请填写审批意见); return; } $.ajax({ url: /leave/audit, type: POST, data: {leaveId: leaveId, auditStatus: auditStatus, comment: comment}, dataType: json, success: function (res) { if (res.code 0) { // 关闭当前弹层刷新待办表格 layer.closeAll(); reloadTable(); } else { layer.msg(res.msg); } }, error: function () { layer.msg(网络异常请稍后重试); } }); }前端交互有一个细节做得不好的系统在浏览器控制台里会报Failed to load resource: the server responded with a status of 401而页面却没有任何提示。原因就是后端的拦截器对AJAX请求返回了重定向而不是JSON。前后端联调时这类问题要用浏览器的开发者工具查看“网络”标签页看到X-Requested-With请求头的值就能推理出是不是走错了拦截分支。5. 避坑手册部署这套OA系统最常见的5个坑与排查路径5.1 数据库脚本执行报错多个SQL文件按什么顺序导入现象导入.sql脚本时报Table xxx doesnt exist或外键约束失败。原因资源包里的数据库脚本可能不止一个文件。常见做法是分schema.sql建库建表和data.sql初始数据两个文件如果存在sys_menu表的parent_id引用了自身的主键导入顺序不对或分开执行时忽略了外键检查就会报错。解决用命令行一次性导入不要让数据库工具分步执行。并且临时关闭外键检查mysql -u root -p oa_system -e SET FOREIGN_KEY_CHECKS0; SOURCE /path/to/schema.sql; SOURCE /path/to/data.sql; SET FOREIGN_KEY_CHECKS1;导入成功后查一下核心表的数据条数SELECT COUNT(*) FROM sys_user; SELECT COUNT(*) FROM sys_menu;如果sys_menu是空表登录进去就没有菜单页面会白板。遇到这种情况别急着看代码先确认基础数据在不在。5.2 Tomcat部署后访问404上下文路径和静态资源路径对不上现象项目部署到Tomcat后能打开登录页但登录成功后跳转到/index返回404。原因SSM项目的spring-mvc.xml里配了静态资源映射mvc:resources mapping/static/** location/static/ /但如果项目打包后的war包名是OA系统.warTomcat访问路径就带了上下文名页面里写的/static/js/main.js就会因为缺少上下文前缀而加载失败。解决JSP页面里用${pageContext.request.contextPath}拼接静态资源路径。排查时打开浏览器开发者工具看Network面板里静态资源请求的状态码和URL如果URL缺上下文名就要全局搜索替换写死的/static/路径。这类“登录页出来了但页面样式全丢了”的问题十有八九是上下文路径引起的血泪经验。5.3 中文乱码贯穿始终过滤器、数据库、JSP三处一起查现象页面上表单提交的中文显示为问号或者数据库里存进去的是乱码。原因乱码问题通常是三处不一致叠加导致的JSP页面编码、Spring的CharacterEncodingFilter过滤器、数据库连接URL里的characterEncoding参数。只改其中一处解决不了问题。解决按以下顺序逐项核对。第一JSP页面头部确认% page contentTypetext/html;charsetUTF-8 languagejava pageEncodingUTF-8 %第二Spring的编码过滤器要放在web.xml过滤器链的第一个位置filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param init-param param-nameforceEncoding/param-name param-valuetrue/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping第三数据库连接URL里带上characterEncodingutf8。三处都确认后重启Tomcat再试。如果数据库里已有的乱码数据用UPDATE配合CONVERT函数修复别指望代码层面能自动恢复已经写坏的字符。5.4 JDK版本不匹配导致的编译失败看到cannot find symbol先看依赖坐标现象mvn compile报大量cannot find symbol或package javax.servlet does not exist。原因pom.xml 里依赖的框架版本和当前JDK不匹配。Spring Boot 3.x 依赖jakarta.servlet但代码里引用的还是javax.servlet.http.HttpServletRequest或者项目用了 Lombok但JDK版本太新Lombok版本太旧注解处理器没生效。解决先定位JDK版本再决定方向java -version mvn -v如果项目是Spring Boot 2.x JDK 8但你本机只有JDK 17可以修改pom.xml里的java.version为1.8同时确认maven-compiler-plugin的source和target也是1.8。如果是代码里用了javax.*但依赖里只有jakarta.*说明这是个Spring Boot 3.x项目要么换JDK 17硬编过要么用工具批量替换 import 路径。多数情况下企业里的OA系统还是以 Spring Boot 2.x JDK 8 组合为多遇到报错先看版本比盲目搜索报错信息有效得多。5.5 登录一直失败且无错误提示检查数据库里初始密码的加密方式现象资源包说明文档写着账号admin密码admin123但登录时一直提示“用户名或密码错误”控制台也没有SQL异常。原因这套OA若用MD5加密存储密码而数据库脚本里的初始数据可能存了21232f297a57a5a743894a0e4a801fc3admin123的MD5。但如果你用的代码是从别的版本拷贝来的密码校验逻辑可能是MD5盐或者用了BCrypt两者对不上。解决查看sys_user表里密码字段的格式。MySQL里可以用如下方式比对SELECT user_id, username, password FROM sys_user; -- 对比 MD5 加密结果 SELECT MD5(admin123);如果发现password字段是$2a$10$开头的BCrypt格式说明代码用BCryptPasswordEncoder做校验。这时候最简单的办法是直接改库生成一个BCrypt密文再UPDATE进去。更通用的做法是打开登录Controller找到密码校验那一行看调的是MD5Util还是BCrypt然后用对应的方法重新生成密码。遇到这种问题千万别想着绕过登录逻辑顺着代码找到校验方式五分钟就能解决。6. 在OA源码包基础上做二次开发的进阶路径与效果验证拿到这套源码并跑通之后下一步是往里面加自己的东西。这里给出一条从易到难的路径先做数据权限再做消息通知最后引入真正的工作流引擎。每条路径做完都要有一个可验证的标准。数据权限是很多人忽略但企业里高频需要的功能。目前的员工登录系统后理论上能看到所有请假单而正确做法是部门经理只看本部门。实现思路是在查询oa_leave的SQL里根据当前用户的角色动态拼接数据范围条件。比如普通员工拼AND user_id #{currentUserId}部门经理拼AND dept_id #{currentUserDeptId}。用MyBatis的if标签很容易做select idselectLeaveList resultTypeOaLeave SELECT * FROM oa_leave where if testdataScope self AND user_id #{currentUserId} /if if testdataScope dept AND dept_id #{currentUserDeptId} /if /where ORDER BY create_time DESC /select改完后用两个账号分别登录验证管理员能看到全量数据普通员工只能看到自己提交的申请并且互相看不到对方的。这一步做完你对RBAC模型的理解就超过了只会写登录注册的人。消息通知的进阶可以做成站内信或集成WebSocket实时推送。最简单的实现是建一张oa_notification表审批通过后往这张表插数据用户登录后查询未读消息更实时一点的做法是用spring-boot-starter-websocket审批动作发生时向前端推送一条WebSocket消息前端页面做成消息角标提醒// 前端建立 WebSocket 连接以 Spring Boot 项目为例 var socket new WebSocket(ws:// window.location.host /ws/notify); socket.onmessage function (event) { // 收到消息后刷新右上角未读角标 loadUnreadCount(); };验证方式是打开两个浏览器窗口一个窗口提交请假单另一个窗口用管理员登录看能否在不手动刷新页面的情况下自动出现待办提醒。这一步做成功后系统体验感会上升一个档次。最后一条进阶路径是引入Activiti工作流引擎。当审批层级超过三级、出现会签、加签、驳回指定节点等复杂流程时纯手工用status字段拼状态机已经守不住了。常见做法是引入activiti-spring-boot-starter把oa_leave的业务数据和ACT_RU_TASK的流程实例关联起来。这是一个比前两项大得多的工程建议先把数据权限和消息通知做完对这套代码的业务模式摸透了再动工作流。跑完这些进阶路线后再做一次系统的整体验证用JMeter对登录接口跑100个线程看有没有并发Session问题同时把oa_audit_record表的数据导出来检查事务一致性。OA系统是给全公司用的稳定性比酷炫的界面重要得多。我个人的习惯是做完一个功能改动后先把application.yml里日志级别调到DEBUG跑一遍主流程确认没有隐藏异常再往上游发。这个习惯帮我避开过不少上线后才发现的黑匣子问题。希望帮到你。本文还有配套的精品资源点击获取