简介这是一套基于SpringBoot的Java协同办公OA系统源码面向需要学习企业级办公自动化开发或搭建内部管理平台的开发者适合具备Java Web与SpringBoot基础的进阶学习者。系统前台采用springbootfreemarkerjpamybatismysql组合后台以SpringBoot为核心持久层融合JPA与MyBatis模板引擎使用FreeMarker整体结构完整、模块划分清晰。压缩包共2443个文件约25.54MB涵盖285个java源码、301个ftl模板、172个js脚本、122个css样式、106个xml配置及78个html页面另有png、gif等静态资源与少量sql、properties文件便于直接部署与二次开发。功能覆盖系统管理、用户管理、考勤管理、流程管理、公告管理、邮件管理、任务管理、日程管理、计划管理和文件管理十大模块包含数据字典、角色权限、费用报销、出差加班申请、内部邮件附件、文件归档分享等完整业务链路。目前已有872人学习下载可作为OA项目实战参考与毕业设计素材。1. 从一份 Java 协同办公 OA 系统源码说起它到底能跑出什么很多做 Java 后端的兄弟工作三五年后都会遇到一个尴尬简历上写着熟悉 Spring Boot、MyBatis但真让他从零搭一套带权限、带流程、带附件的业务系统脑子里是空的。面试官问一句你这个权限模型怎么设计的就开始支支吾吾。这份 Java 协同办公 OA 系统源码解决的就是这个断层——它不是玩具级的 CRUD demo而是一套把组织架构、角色权限、审批流程、公告通知、考勤打卡、文件管理这些真实办公场景串起来的完整工程。它适合三类人一是想拿一套能跑通的企业级项目练手、补全业务认知的初中级 Java 工程师二是需要快速交付一套内部办公系统、又不想从零造轮子的外包或中小企业技术负责人三是准备 Java 面试、想拿真实项目讲清楚权限怎么落地流程怎么驱动的求职者。源码基于 Spring Boot MyBatis-Plus 这套主流组合前端常见做法是 Vue 或 Thymeleaf 服务端渲染数据库 MySQL缓存 Redis整体结构清晰改起来不费劲。下面我按能跑起来 → 能改明白 → 不踩坑的顺序把这份源码拆开讲。2. 环境准备与工程结构把项目在本地跑起来拿到一份源码最怕的就是能看懂但跑不起来。OA 系统这类项目依赖多、模块杂环境没对齐启动就报一堆找不到 Bean 的错。这一章先把运行环境和工程骨架理清楚让你在本地把服务拉起来看到登录页。2.1 运行环境与依赖版本对齐OA 系统对 JDK 和中间件版本比较敏感尤其是 MyBatis-Plus 和 Spring Boot 的版本匹配。常见做法是 JDK 8 或 JDK 11Spring Boot 2.x 系列MySQL 5.7 或 8.0。下面这套组合是我实测比较稳的组件推荐版本说明JDK8 / 118 兼容性最好11 需注意部分反射警告Spring Boot2.7.x与 MyBatis-Plus 3.5.x 匹配良好MyBatis-Plus3.5.2分页、逻辑删除、代码生成都靠它MySQL5.7 / 8.08.0 注意驱动类名和时区参数Redis5.0存 token、验证码、在线用户Maven3.6依赖拉取注意私服配置环境变量配置是新手第一道坎。JAVA_HOME指向 JDK 根目录Path里加上%JAVA_HOME%\bin配完在命令行敲java -version和mvn -v确认。这一步翻车的人不少多半是路径里带了空格或者指向了 JRE 而不是 JDK。2.2 工程目录结构与模块职责一份规范的 OA 源码目录结构基本遵循分层约定。典型结构如下oa-system/ ├── oa-common/ # 公共模块工具类、常量、统一返回体 ├── oa-framework/ # 框架配置安全、拦截器、全局异常 ├── oa-system/ # 系统管理用户、角色、菜单、部门 ├── oa-workflow/ # 流程引擎审批、任务、流转记录 ├── oa-admin/ # 启动模块主类和配置文件 └── sql/ # 初始化脚本oa-common放的是全项目复用的东西比如Result、PageResult、日期工具、加密工具。oa-framework是配置层Spring Security 或 Shiro 的配置、JWT 拦截器、跨域配置都在这里。oa-system是权限核心用户-角色-菜单三张主表加两张关联表。oa-workflow是流程模块如果源码用的是 Activiti 或 Flowable引擎配置也在这。oa-admin是入口application.yml在这里。理解这个分层后面改代码才知道该动哪个模块。我一般会先看oa-admin的启动类和配置文件再顺着 Controller 往下捋。2.3 数据库初始化与配置修改跑起来的关键一步是导数据。源码的sql目录下通常有建表脚本和初始数据脚本按顺序执行-- 1. 创建数据库字符集用 utf8mb4否则中文和表情会乱码 CREATE DATABASE oa_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 2. 执行建表脚本表结构 source /path/to/sql/oa_schema.sql; -- 3. 执行初始化数据管理员账号、菜单、角色 source /path/to/sql/oa_data.sql;导完数据改application.yml里的数据源配置spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/oa_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的密码 redis: host: localhost port: 6379 database: 0serverTimezone必须配MySQL 8.0 不配会报时区错误。useSSLfalse本地开发关掉省得证书告警。Redis 如果没设密码password留空即可。配置改完mvn clean package打包或者直接在 IDE 里跑oa-admin的主类。看到控制台打印启动成功、端口监听浏览器访问http://localhost:8080出现登录页这一步就成了。默认管理员账号一般在初始化脚本里常见是admin/admin123具体看源码注释。3. 权限模型与流程引擎OA 系统真正的技术内核跑起来只是第一步OA 系统的价值在于权限和流程这两块。面试被问得最多的也是这两块。这一章把 RBAC 权限模型和审批流程的实现逻辑拆开让你不光会用还能讲清楚为什么这么设计。3.1 RBAC 权限模型用户-角色-菜单的落地OA 系统的权限几乎都是 RBAC基于角色的访问控制模型。核心是五张表用户表、角色表、菜单权限表加两张关联表user_role和role_menu。用户通过角色关联到菜单菜单里既有页面路由也有按钮权限。为什么用 RBAC 而不是直接给用户配权限因为企业里人员流动频繁直接配用户权限人一走权限就乱。角色是稳定的岗位职责不变角色权限就不动换人只换用户和角色的绑定关系。这是选型上的核心考量。权限校验的落地分两层。第一层是接口级用 Spring Security 或自定义注解 拦截器判断当前用户有没有访问某接口的权限。第二层是数据级比如部门经理只能看本部门数据这就要在 SQL 里拼部门条件或者用 MyBatis-Plus 的拦截器做数据权限过滤。// 自定义权限注解标在 Controller 方法上 Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequiresPermission { String value(); // 权限标识如 system:user:add } // 拦截器里校验 public class PermissionInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (!(handler instanceof HandlerMethod)) return true; HandlerMethod method (HandlerMethod) handler; RequiresPermission anno method.getMethodAnnotation(RequiresPermission.class); if (anno null) return true; // 从当前登录用户上下文取权限集合 SetString perms SecurityUtils.getCurrentUserPermissions(); if (!perms.contains(anno.value())) { throw new BusinessException(无权限访问); } return true; } }RequiresPermission的value对应菜单表里的权限标识登录时把用户所有权限查出来放进上下文。拦截器在方法执行前比对没有就抛异常。这样权限控制就集中在一处不用每个方法里写 if 判断。参数上要注意权限标识的命名规范要统一常见是模块:功能:操作比如system:user:add命名乱了后期维护很痛苦。3.2 审批流程引擎从申请到归档的驱动逻辑协同办公的核心场景是审批请假、报销、采购、用章。流程引擎负责把谁在什么节点做什么串起来。源码里常见两种实现轻量级用状态机自己写重量级用 Activiti 或 Flowable。轻量级状态机适合流程简单、节点固定的场景。核心是一张流程实例表和一张任务表每个节点对应一个状态审批动作驱动状态流转。// 流程实例状态枚举 public enum ProcessStatus { DRAFT, // 草稿 PENDING, // 待审批 APPROVED, // 已通过 REJECTED, // 已驳回 CANCELED // 已撤销 } // 审批动作 public void approve(Long taskId, String comment, boolean pass) { Task task taskMapper.selectById(taskId); if (task null || !task.getStatus().equals(PENDING)) { throw new BusinessException(任务不存在或已处理); } task.setComment(comment); task.setStatus(pass ? APPROVED : REJECTED); task.setFinishTime(new Date()); taskMapper.updateById(task); // 通过则流转到下一节点驳回则回到发起人 if (pass) { moveToNextNode(task); } else { backToInitiator(task); } }approve方法接收任务 ID、审批意见和是否通过。先校验任务状态防止重复审批——这是血泪经验不加状态校验用户连点两次提交流程就乱了。通过则调moveToNextNode找下一节点驳回则backToInitiator退回。moveToNextNode里要根据流程定义查下一个审批人可能是固定角色也可能是发起人的上级这取决于流程配置。如果源码用的是 Flowable那流程定义是 BPMN 2.0 的 XML 文件部署后通过RuntimeService启动实例TaskService查询和完成任务。这种方案灵活能画流程图但学习成本高改流程要动 XML。选哪种看业务复杂度节点经常变的用引擎节点固定的状态机足够。3.3 附件上传与在线预览的实现OA 里请假要传证明、报销要传发票附件是刚需。上传本身不难难的是存储策略和预览。存储上小规模直接存本地磁盘配个静态资源映射规模大了上 MinIO 或对象存储。源码里常见做法是存本地路径配在application.ymlfile: upload-path: /data/oa/upload/ access-url: http://localhost:8080/file/上传接口用MultipartFile接收重命名用 UUID 防冲突按日期分目录避免单目录文件过多public String upload(MultipartFile file) { String original file.getOriginalFilename(); String ext original.substring(original.lastIndexOf(.)); String datePath new SimpleDateFormat(yyyy/MM/dd).format(new Date()); String fileName UUID.randomUUID().toString().replace(-, ) ext; File dest new File(uploadPath datePath / fileName); if (!dest.getParentFile().exists()) dest.getParentFile().mkdirs(); file.transferTo(dest); return accessUrl datePath / fileName; }ext取扩展名保留格式datePath按天分目录UUID做文件名防重名和遍历攻击。transferTo落盘前先建父目录否则目录不存在直接报错。在线预览这块图片和 PDF 浏览器能直接打开Office 文档常见做法是转 PDF 或用第三方预览服务源码里如果没集成可以自己接。4. 二次开发避坑那些跑起来才会暴露的问题源码能跑不等于能用真正上手改的时候坑一个接一个。这一章把我在 OA 二次开发里踩过的典型问题列出来每条按现象、原因、解决三步走帮你省点排查时间。4.1 登录后菜单不显示或权限失效现象登录成功但左侧菜单空白或者点某个功能提示无权限。原因多半是菜单数据没初始化全或者用户角色没绑定菜单。RBAC 里菜单是跟着角色走的新用户没分配角色或者角色没关联菜单权限集合就是空的。还有一种情况是前端路由和后端菜单对不上后端返回了菜单但前端没渲染。解决先查user_role表确认用户有角色再查role_menu确认角色有菜单最后看菜单表的visible和status字段是不是被置成了隐藏或停用。前端对不上的话检查菜单表里的路由地址和前端路由配置是否一致。4.2 流程审批重复提交导致状态错乱现象用户快速点两次通过流程跳过了中间节点或者同一任务出现两条审批记录。原因接口没做幂等前端也没防重复点击。第一次请求改了任务状态第二次请求进来时状态已经变了但代码没校验又执行了一遍流转。解决在审批方法里加状态校验只有PENDING状态才允许处理处理时用数据库乐观锁或update ... where status PENDING保证原子性。前端按钮点击后置灰双保险。4.3 附件上传中文名乱码或路径穿越现象上传中文名文件后下载时文件名乱码或者上传了带../的文件名文件落到了预期目录外。原因中文乱码是编码没统一路径穿越是文件名没做安全过滤。MultipartFile的原始文件名直接拿来用攻击者可以构造恶意路径。解决文件名统一用 UUID 重命名不直接用原始名。如果必须保留原名做replaceAll(\\.\\./, )过滤并且落盘前用getCanonicalPath()校验目标路径在允许目录内。中文乱码在响应头里设Content-Disposition时用URLEncoder.encode(name, UTF-8)。4.4 分页查询数据量大时变慢现象用户列表、日志列表翻到后面几页响应明显变慢。原因MyBatis-Plus 的分页默认用limit offset, sizeoffset 很大时 MySQL 要扫描并丢弃前面所有行越翻越慢。加上如果查询条件没走索引全表扫描更慢。解决大表分页改用游标方式用上一页最后一条的 ID 做条件where id lastId limit size。或者限制最大翻页数引导用户用搜索缩小范围。索引方面给查询条件字段和排序字段建联合索引用explain看执行计划确认走没走索引。4.5 定时任务与多节点部署冲突现象考勤统计、消息推送这类定时任务部署两个节点后任务执行了两次数据重复。原因定时任务没做分布式锁每个节点都触发。单机跑没问题一上集群就暴露。解决用 Redis 分布式锁或 Quartz 的集群模式保证同一时刻只有一个节点执行。简单做法是任务执行前setnx抢锁抢到才跑跑完释放。或者干脆把定时任务拆成独立服务只部署一个实例。5. 从能跑到能交付数据权限与性能验证的进阶技巧把系统跑起来、改明白之后真正决定这套源码能不能交付的是数据权限的精细度和性能的可验证性。这两块是区分能演示和能上线的分水岭。5.1 数据权限的三种实现路径功能权限管的是能不能点这个按钮数据权限管的是能看到哪些数据。OA 里典型场景部门经理看本部门普通员工看自己总经理看全部。实现路径有三条。第一条是 SQL 硬编码在 Mapper 的查询里直接拼and dept_id #{deptId}。简单直接但每个查询都要写改起来散落各处。第二条是 MyBatis 拦截器在 SQL 执行前动态改写统一注入数据权限条件。这是主流做法配置一次全局生效Intercepts({Signature(type Executor.class, method query, args {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})}) public class DataScopeInterceptor implements Interceptor { Override public Object intercept(Invocation invocation) throws Throwable { // 取当前用户的数据权限范围 DataScope scope SecurityUtils.getCurrentDataScope(); if (scope null || scope.isAll()) { return invocation.proceed(); // 全部权限不改写 } // 根据 scope 拼接 SQL 条件改写 MappedStatement // 具体实现涉及 BoundSql 解析这里省略细节 return invocation.proceed(); } }拦截器在query方法执行前介入拿到当前用户的数据范围。如果是全部权限就放行否则改写 SQL 加上部门或用户条件。参数上要注意DataScope里通常存范围类型全部/本部门/本部门及以下/仅本人和部门 ID。改写 SQL 时用BoundSql的getSql()和setSql()注意别破坏原有参数映射。第三条是注解 AOP在 Service 方法上标DataScope切面里拼条件。比拦截器灵活但侵入业务代码。选哪条看团队习惯。拦截器统一但调试难注解灵活但要写切面。我一般推荐拦截器因为数据权限是横切关注点集中管理比散落各处好维护。5.2 性能验证压测与慢查询定位系统能不能扛住不能靠感觉要靠数据。上线前至少做两件事接口压测和慢查询排查。压测用 JMeter 或 wrk重点压登录、列表查询、流程提交这几个高频接口。关注三个指标TPS、响应时间 P95、错误率。TPS 上不去先看数据库连接池够不够HikariCP 默认 10 个连接并发高了不够用调到 20-50 看机器配置。响应时间 P95 超过 500ms 就要查慢查询。慢查询排查开 MySQL 的慢日志-- 查看慢查询配置 SHOW VARIABLES LIKE slow_query%; SHOW VARIABLES LIKE long_query_time; -- 开启慢日志阈值设 1 秒 SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;日志里找到慢 SQL用explain看执行计划。重点看type是不是ALL全表扫描key是不是NULL没走索引rows扫描行数大不大。OA 里最容易出问题的是用户列表和日志列表数据量大又常带模糊查询。模糊查询like %xxx%走不了索引能改成前缀匹配like xxx%就改改不了就上全文索引或搜索引擎。5.3 一个我坚持的习惯这套源码我从头到尾捋过一遍最大的体会是别急着改业务代码先把权限和流程这两条主线在脑子里跑通。我现在的习惯是拿到任何一套 OA 源码先画三张图——权限关系图、流程状态图、数据流向图。图画完哪块能复用、哪块要重写心里就有数了。改之前先跑通、先压测、先看慢日志别等上线了才发现分页翻到第十页卡死。从那以后我每次接二手项目都强制走一遍跑通 → 压测 → 看日志的流程省下的排查时间远比前期投入多。希望这套源码和这些经验能帮你在 OA 这条路上少走点弯路。本文还有配套的精品资源点击获取