简介面向需要搭建办公自动化系统的Java开发者这份基于Spring Boot、Maven与MySQL的OA系统源码覆盖日常办公管理核心功能可帮助理解企业级项目从分层架构到数据持久化的完整落地路径。压缩包共1031个文件以237个Java源文件为主干配合152个FreeMarker模板、85个JS、56个CSS与39个HTML组成前端交互层另含SQL数据库脚本、properties配置及大量png/gif示意图片整体仅5.49MB结构紧凑便于按模块检索其中SQL脚本可直接导入MySQL使用。目前已有1899人学习适合正在研究Spring Boot整合或需要快速搭建OA原型的开发者。通过源码可掌握文件上传接口、后台管理页面动态渲染及多表关联查询等关键实现还能参考asp/php等辅助脚本了解跨语言接口写法配合完整目录组织能有效支撑二次开发与功能扩展。1. 一套Java写的OA自动化办公系统源码到底能不能拿来就用手头有一套“Java开发OA自动化办公系统源码.zip”不是每个打开压缩包的人都能把它跑起来。我见过太多人解压之后对着application.yml、pom.xml和一堆看不懂的数据库脚本发呆然后去搜索引擎里翻“泛微oa e10 初始密码”“致远oa管理员培训”这类词——那不是在看源码那是在找后悔药。这个标题真正要回答的问题是这套源码是什么技术栈、能不能在本地跑通、业务功能做到什么程度、二次开发要动哪些地方。适合的人有两类一类是Java初学者想借一套完整系统搞懂企业级项目的模块划分另一类是中小团队想快速搭一个内部办公系统不想从零写组织架构、审批流和权限模型。这篇文章会从工程视角把它拆开给出能直接复现的步骤、参数和坑。2. 拆解这套OA源码之前先搞清技术选型为什么这么走2.1 从包名和依赖入手判断项目的真实结构拿到OA自动化办公系统源码.zip我第一件事不是看代码而是看根目录。通常一个规范的Maven项目会带着pom.xml、src/main/java、src/main/resources和sql或db目录。如果压缩包里连pom.xml都没有说明它可能是Eclipse工程或者远古时代的Java Web项目——那种带着.classpath和.project文件的古董跑起来的成本会高一个量级。常见做法是这类OA源码会用Spring Boot作为底座因为它的自动配置能极大减少XML配置。到了2024年往后还在用SSHStruts2 Spring Hibernate结构的OA源码不太多了即使是老项目多数也完成了向Spring Boot的迁移。我一般会先看pom.xml里的依赖树确认三件事主框架版本是Spring Boot 2.x还是3.x、持久层用的是MyBatis还是MyBatis-Plus还是JPA、权限方案是Spring Security还是Shiro还是自己写拦截器。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency /dependencies这是一套很典型的现代OA技术底座。选Spring Boot是因为它天然适合这种“模块多、配置杂、要快速集成”的企业系统选MyBatis-Plus是因为OA里的报表统计、多条件分页查询非常多单表CRUD用它的Wrapper能少写一半样板代码选Spring Security则是因为OA必须面对组织架构、菜单权限、数据权限三层的复杂控制Shiro虽轻但到数据级权限就吃力了。版本上2.7.18是Spring Boot 2.x的最后一个社区维护版稳定坑少JDK 8到17都能跑适合作为这种源码的底座。如果发现这个项目的Spring Boot版本是3.x那就要注意JDK必须17往上且javax.servlet包会变成jakarta.servlet导入老代码时需要批量替换。这一条最容易让人第一次启动就翻车。2.2 看清“自动化办公”在Java源码里具体指什么“自动化办公系统”是一个很宽泛的词。搜索热词里同时出现“泛微OA”“致远OA”“蓝凌OA”说明很多人印象中的OA是这些商业产品的样子——有门户、有流程引擎、有知识库。但一套被称为“源码”的Java OA项目不可能达到商业产品的高度它的“自动化”通常落在三个具体点上。第一是审批流的自动化请假、报销、用章申请从发起到归档全走线上第二是消息提醒的自动化待办、催办、抄送通过站内信或邮件去触达第三是数据汇总的自动化考勤、日报、项目工时自动汇成报表。判断一套OA源码值不值得跑就看这三块是不是真的实现了而不是只有一张登录页和一两个CRUD。我在打开源码后一般会先搜索controller包里的接口数量如果整个系统只有login、user、dept这几个入口那它就是个壳不值得往下看。自动化办公系统的核心价值是“把线下流程搬到线上并留下痕迹”所以源码里最值得读的是workflow模块和message模块。工作流模块的实体关系、消息模块的推送时机才是这套源码的含金量所在。后面会专门拆工作流的部分。2.3 数据库脚本是整个源码能否复现的分水岭解压之后先找.sql文件放在哪个目录然后用数据库客户端跑一遍建表脚本。这套系统的表结构通常包括sys_user、sys_role、sys_menu、sys_dept、oa_leave、oa_reimburse、oa_notice、oa_message、act_*这些前缀的表——如果出现act_前缀说明工作流引擎用的是Activiti或Flowable那种情况源码的技术深度会高一些踩坑点也多一些。-- 标准的OA用户表结构注意这里省略了字段注释之外的部分 CREATE TABLE sys_user ( user_id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 用户ID, dept_id bigint(20) DEFAULT NULL COMMENT 部门ID, user_name varchar(30) NOT NULL COMMENT 登录账号, nick_name varchar(30) NOT NULL COMMENT 用户昵称, email varchar(50) DEFAULT COMMENT 邮箱, phonenumber varchar(11) DEFAULT COMMENT 手机号码, sex char(1) DEFAULT 0 COMMENT 性别, avatar varchar(100) DEFAULT COMMENT 头像地址, password varchar(100) DEFAULT COMMENT 密码, status char(1) DEFAULT 0 COMMENT 帐号状态0正常 1停用, del_flag char(1) DEFAULT 0 COMMENT 删除标志0存在 2删除, create_time datetime DEFAULT NULL COMMENT 创建时间, PRIMARY KEY (user_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT用户信息表;注意两个点。第一是字符集老源码经常是utf8而不是utf8mb4如果系统里要录入Emoji比如企业微信昵称utf8会报“Incorrect string value”错误跑核心脚本前统一改成utf8mb4能省掉后面一堆编码问题。第二是ENGINEInnoDB如果脚本里出现MyISAM意味着这套源码当年没考虑事务报销审批这种写多个表的场景会有一致性隐患。跑脚本前我习惯把sql_mode里的ONLY_FULL_GROUP_BY去掉因为很多老OA的统计SQL在严格模式下直接报错这是最常见的数据库脚本翻车点。3. 在本地把OA源码跑起来最小可行启动流程3.1 前置环境JDK、Maven、MySQL的版本怎么配先列一套我验证这类OA源码时用的环境组合再说明每个组件的边界。JDK用1.8即8u202之后的版本Maven用3.6.3或3.8.xMySQL用5.7或8.0Redis如果有集成就用5.x以上。这套组合的兼容性最广能覆盖绝大多数Spring Boot 2.x时代的OA源码。如果源码里明确写了Spring Boot 3.x或者Spring Cloud Alibaba那JDK必须切到17Maven用3.9.x。不要幻想用JDK 17跑老项目java.lang.NoClassDefFoundError会教你做人。在Windows上配置环境变量时注意JAVA_HOME不要再指向C:\Program Files\Java\jdk1.8.0_301\jre那是安装时容易犯的错——必须指到JDK的根目录否则IDE和命令行看到的是不同的运行时。# Linux / macOS 下用 sdkman 管理 JDK 版本切换 sdk install java 8.0.392-tem sdk use java 8.0.392-tem # 验证当前环境 java -version mvn -version mysql --version这三个命令的输出决定了后续所有步骤是否值得进行。我见过有人卡在mvn -version报Unsupported major.minor version 52.0——那是因为Maven本身需要JDK 7以上而JAVA_HOME指向了JRE。这类问题看起来低级但在给客户部署时出现频率极高判断环境时务必直接看命令回显不要相信系统设置面板里的字符串。3.2 初始化数据库并修正连接配置找到源码包里sql或db目录下的主脚本通常是oa_init.sql或oa_full.sql。用命令行或Navicat执行之前先建一个空库库名建议和脚本里的保持一致避免去改脚本里的USE语句。# 登录 MySQL 后执行 CREATE DATABASE oa_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE oa_system; SOURCE /path/to/your/oa_init.sql; # 验证表是否建全 SHOW TABLES;执行完SHOW TABLES应该能看到几十张表数量太少就要怀疑脚本是不是只建了核心表初始化数据尤其是部门树、菜单表、角色表有没有成功插入。sys_menu表通常有几百行初始数据如果只有几条登录进去会看到一片空白菜单。源码里若带有data.sql和schema.sql这种Spring Boot惯用文件名Spring Boot会在启动时自动执行它们但多数OA源码不会这么设计而是要求手动导入主脚本。之后改application-druid.yml或application.yml里的数据源。重点检查username、password、url三个字段URL里要带上useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai不然时间字段和中文会出现灵异现象。还要确认driverClassName是com.mysql.cj.jdbc.Driver而非com.mysql.jdbc.Driver后者只在老驱动里有效在MySQL 8.0连接器下会直接启动失败。spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driverClassName: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/oa_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_mysql_password initialSize: 5 minIdle: 5 maxActive: 20这些参数里maxActive20是中小型OA的合理选择。OA系统的并发特征不是高QPS而是大量长连接和短事务连接池太小会导致高峰期报CannotGetJdbcConnectionException太大则浪费MySQL的连接数上限。initialSize和minIdle保持5就够了没必要设成100。3.3 启动入口和第一个登录请求多数OA源码的主类是com.oa.OaApplication或者OaApplication.java用IDE直接运行或者在项目根目录执行mvn spring-boot:run。看到Started OaApplication日志后打开浏览器访问http://localhost:8080。如果端口不是8080检查application.yml里的server.port。# 编译并启动跳过测试避免 test 阶段报环境相关的错 mvn clean package -DskipTests java -jar target/oa-system-1.0.0.jar第一次启动大概率会遇到两个问题。一个是Redis连不上OA源码喜欢把验证码、Token缓存到Redis启动时连不上会直接报错退出——如果源码不强依赖Redis可以在配置里注释掉Redis的自动配置或者在本地起一个带默认密码的空实例。另一个是静态资源路径错乱登录页能出来但验证码图片不显示通常是Kaptcha组件的字体文件在Linux上找不到往服务器/usr/share/fonts里丢一个中文字体就能解决。登录接口返回的Token决定了后续所有操作能否继续。用命令行验证一下接口是否通才能确定前后端联调的边界在哪里。curl -X POST http://localhost:8080/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123}如果返回JSON里带有token字段说明认证链路是通的。之后把这段Token放到Authorization: Bearer token请求头里再访问/system/user/list之类的接口测试数据权限。很多读者在这步直接打开浏览器登录页报错就认为是源码不行——其实一半以上的启动失败都出在数据库版本或Redis环境上跟代码本身的逻辑无关。4. OA自动化办公系统的三大核心模块怎么改、参数怎么调4.1 组织架构与权限模型树表结构怎么设计才不踩坑OA和普通管理系统最大的区别在组织架构。sys_dept表以parent_id和ancestors两个字段维护树结构ancestors存的是从根到当前节点的ID路径用逗号分隔。这个设计在查询“某个部门下所有子部门的人”时非常高效一条LIKE就能搞定但在数据量超过几千条时ancestors LIKE %xx%会全表扫。改法也不难维护一张闭包表或者在业务查询里改成先查子树再查人。-- 典型OA查询查某个部门及其所有子部门下的人员 SELECT u.user_id, u.user_name, d.dept_name FROM sys_user u JOIN sys_dept d ON u.dept_id d.dept_id WHERE d.ancestors LIKE CONCAT(%,, #{deptId}, ,%) OR d.dept_id #{deptId};权限方面这套源码如果基于Spring Security会有一个PreAuthorize注解标在Controller上。它的表达式通常是hasPermi(system:user:add)对应sys_menu表里的perms列。二次开发时新增一个按钮权限流程是在菜单表插入一行记录再给角色关联上而不是去改Java代码里的硬编码。如果源码里出现大量user.getRoleId()这种手写判断说明它的权限管理还停留在“能登录就行”的阶段数据级权限比如部门经理只看本部门数据大概率没做那种情况就别指望扩展了。4.2 审批流的“自动化”到底自动在哪状态机与工作流引擎“自动化办公系统”的含金量集中在审批流。商业OA泛微、致远靠的是自研流程引擎能画节点、能配条件。源码型项目一般只有两种实现一种是自己写状态机用status字段加if/else推进另一种集成Activiti或Flowable走BPMN 2.0标准。前者轻量、好改、适合中小团队后者流程可视化但学习成本高、和业务代码耦合时容易翻车。看清源码用哪种决定了后续所有二次开发的姿势。如果是自研状态机核心逻辑通常会集中在WorkflowService里。一个请假申请的流转大概长这样public void approve(Long taskId, Integer userId, Boolean pass, String comment) { WorkflowTask task workflowTaskMapper.selectById(taskId); // 核心根据当前节点决定下一个节点 if (task.getStatus() 1) { // 1 - 部门经理审批 if (pass) { task.setStatus(2); task.setCurrentApprover(deptManagerId(task.getApplicantId())); } else { task.setStatus(-1); } } else if (task.getStatus() 2) { // 2 - 人事归档 if (pass) { task.setStatus(3); } else { task.setStatus(-1); } } task.setUpdateTime(LocalDateTime.now()); workflowTaskMapper.updateById(task); // 审批通过后写消息触发待办通知 messageService.notify(task); }这段代码的逻辑说明状态机以status明确定义当前审批所处节点每一步审批都判断当前状态和操作结果然后推进到新节点或驳回终态。currentApprover字段存的是当前节点审批人的用户ID用来支撑待办查询。messageService.notify(task)是自动化体验的关键——审批完成后下一节点的人要实时收到待办提醒这一步没做系统立刻退回“手工时代”。参数设计上有两个地方必须改。一个是驳回的分类真正好用的OA至少要区分“驳回修改”和“终止流程”前者回到申请人草稿状态后者直接归档——上面的代码把两者全打成-1实际业务里这会造成用户困惑。另一个是审批人设置deptManagerId从哪来sys_dept表里如果没存leader字段就得去sys_user表按dept_id和role_id联合查这决定了后续加“指定审批人”功能时要动多少代码。4.3 消息与待办的推送明明发出去为何读不到消息模块最常见的坑是“待办数量不对”和“已读未读状态错乱”。根源在于OA系统里消息的接收人经常是角色或部门而非单一用户——如果用send_to_user_id存单用户那“发给全体财务”就得循环插入几百条消息性能和设计都不合适。正确做法是拆两张表oa_message存消息本体oa_message_receiver存接收人、已读状态、阅读时间。这类源码若是单表设计可以按这个思路补一张关联表来解耦。另一个高频坑是消息与站内信的会话。OA源码里经常把“审批待办”和“站内通知”混在一张表里导致已办的流程在待办列表里不清空用户每天被无效提醒轰炸。合理的做法是在oa_message表加biz_type字段区分TODO和NOTICE查询时用status和biz_type联合过滤。如果源码里没有这个字段手工补一个并做一次数据订正就能显著改善使用体验。配置层面如果消息要推到企业微信或钉钉通常需要在application.yml里配置Webhook地址和加签密钥。这些内容在源码里会以appId、secret等形似默认值的占位符存在上线前必须替换成真实值且不要把密钥提交到Git仓库。注意企业微信机器人有每分钟最多20条的消息频率限制OA系统“待办促办”功能上线后很容易触发这个限制消息模块一定要做队列削峰否则会出现“越催越没信”的尴尬。4.4 报表与导出POI操作Word/Excel的注意点OA系统的报表导出逃不开Apache POI。搜索热词里有“java poi word能生成图表吗”答案是能但直接生成图表代码量不小且样式难以控制。更稳妥的落地方式是用模板把带${}占位符的docx或xlsx文件放resources目录运行时用POI填充数据后输出。这样图表、水印、页眉页脚全部提前在Office里画好Java代码只负责填值不会出现“代码生成的图表丑到不敢发给领导”的场面。// 基于 XWPFDocument 做 Word 导出填充模板变量 try (FileInputStream fis new FileInputStream(template/leave.docx); XWPFDocument doc new XWPFDocument(fis)) { // 遍历段落替换 ${name} 占位符 for (XWPFParagraph para : doc.getParagraphs()) { ListXWPFRun runs para.getRuns(); for (XWPFRun run : runs) { String text run.getText(0); if (text ! null text.contains(${name})) { run.setText(text.replace(${name}, leave.getUserName()), 0); } } } try (FileOutputStream out new FileOutputStream(output/leave_ leave.getId() .docx)) { doc.write(out); } }这段代码的说明XWPFParagraph代表Word中的一个段落XWPFRun是段落里带同一格式的片段。替换时的关键点是如果占位符被Office拆分到多个run里Word经常干这事上面这种简单的replace就会漏掉——稳妥做法是先合并同段落的run文本再替换或者用TextBody的getText/setText整段操作。导出Excel时注意SXSSFWorkbook只适合纯数据导出有复杂表头合并样式时XSSFWorkbook才稳定但后者的对象不释放会引起内存溢出大批量导出一定要分页查询和批量写行。5. 避坑手册我在部署Java OA源码时踩过的五条实际坑5.1 启动报错“Failed to configure a DataSource”现象Spring Boot启动时直接红字报错提示无法配置数据源且SpringBootApplication注解旁没有任何排除项。原因项目里引入了spring-boot-starter-data-jpa或Druid依赖但application.yml里的数据源配置没有被加载。最常出现在修改过配置文件名之后——比如把application-dev.yml改成了application.yml但里面的缩进不对YAML解析失败导致连接信息真空。解决先跑一下mvn spring-boot:run看全量日志前20行确认加载的是哪个配置文件再用IDEA的Spring面板看Environment标签里spring.datasource.url是否有值。如果源码里有多个application-*.yml要留意spring.profiles.active项被设成了什么。5.2 登录验证码永远校验失败现象验证码图片能显示但输入“正确”的字符总是报错。原因多数OA用Kaptcha生成验证码并把答案放在Redis或Session里。如果用Redis存验证码且Redis宕过或清空过key那么旧验证码全部失效如果是Session模式那么前端请求验证码接口和登录接口的Cookie没有保持一致——常见于前后端分离前端代理把Cookie路径搞丢了。解决方式查看KaptchaController生成验证码时写入的是Redis还是Session然后顺着请求链路确认浏览器发出的Cookie头有没有带JSESSIONID或TOKEN。另外部分源码对验证码做了“一次性校验”前端先提交了验证码、被拦截器拦下再重试一次第二次必然失败——这种情况把页面刷新重来即可不算代码Bug。5.3 菜单树出现重复节点越查越多现象登录后系统菜单偶尔多出几条重复项刷新后恢复再刷新又重复。原因sys_menu表到sys_role_menu的关联表里出现了重复关联且菜单查询SQL里用了LEFT JOIN没加DISTINCT。这属于初始化数据脚本自带的问题并非运行时产生。解决方法是先查重复关联然后删掉冗余行并给role_id, menu_id加唯一索引兜底。-- 找出重复的角色-菜单关联 SELECT role_id, menu_id, COUNT(*) FROM sys_role_menu GROUP BY role_id, menu_id HAVING COUNT(*) 1; -- 删除重复行保留最小id那行 DELETE a FROM sys_role_menu a JOIN sys_role_menu b ON a.role_id b.role_id AND a.menu_id b.menu_id WHERE a.id b.id;执行后顺手补一个唯一索引防止后续操作再次引入重复数据。这个问题不严重但会直接影响用户信任度——系统管理员看到菜单乱跳会觉得整个系统都不稳定。5.4 审批流卡死状态被改但流程不推给下一人现象审批人点击“同意”后界面提示成功但下一节点的人刷新列表看不到待办。原因这类源码的逻辑最常见的是审批操作里只更新了主表status字段没有生成oa_message记录或者消息表里的receiver_id写错。解决方式在approve(...)方法调用后立刻查询oa_message表里是否多了一条待办记录。如果为零多半是messageService.notify(task)内部根据currentApprover查用户时拿到空值要往前排查deptManagerId。还有一个隐蔽点Transactional事务没提交消息查询用了READ_COMMITTED隔离级别在同一连接里查不到未提交数据。这种时候把消息发送放到事务提交后的TransactionSynchronizationManager.registerSynchronization里最稳妥。5.5 导出Excel中文文件名乱码现象下载的报表文件名是“%E8%80%83%E5%8B%A4.xlsx”或者文件名正常但打开后中文内容乱码。原因文件名乱码是响应头Content-Disposition没有做URLEncoder.encode内容乱码则是Excel模板本身编码问题。解决文件名部分先URLEncoder.encode(fileName, UTF-8)再拼到Content-Disposition里内容乱码要看模板里的字体嵌没嵌入。POI生成的文件乱码几乎总是字体缺失导致的——目标机器上没装中文字体时Excel会用默认字体渲染成乱码或方框。// 正确设置下载文件名兼容主流浏览器 String encodedFileName URLEncoder.encode(fileName, StandardCharsets.UTF_8.toString()) .replaceAll(\\, %20); response.setHeader(Content-Disposition, attachment; filename*UTF-8 encodedFileName); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet);这段代码说明了两个关键参数filename*带UTF-8前缀是RFC 5987标准写法用于告诉浏览器文件名编码方式replaceAll(\\, %20)是为了处理URLEncoder会把空格编码成加号的问题——不替换的话文件名里的空格会在浏览器里显示成加号虽然不影响下载但看着难受。6. 把这套OA源码推向生产的最后一步性能验证与发布技巧源码能在本地跑通只能算第一步真正决定它能不能作为团队内部工具长期运行的是并发能力和部署方式。我习惯上线前做一个轻量压测用Apache JMeter模拟30个用户同时提交请假单、50个用户同时查询待办列表观察/workflow/task/list这个接口的响应时间。若P95超过500ms优先查数据库慢查询而不是去调代码——OA的逻辑基本是单表查询加关联最常见的慢查询出在ancestors LIKE和未经索引的create_time排序上。部署方式上不要用java -jar加nohup的单体裸奔方式。即使是中小团队也建议用systemd管理Java进程让它异常退出时自动拉起。同时要配置JVM参数堆内存根据服务器物理内存设定在-Xms1g -Xmx2g之间——OA系统不是高并发应用堆给太大反而会造成GC长时间停顿。编译发布时还有一个容易漏掉的细节源码包里的resources目录下可能含有application-prod.yml、application-test.yml这些文件打包时会把全套配置都带进jar。如果不希望生产配置泄露在工件里打包时单独指定profile过滤。这一步在商业项目里很常见源码项目里也应当保留这个习惯。最后我想说的是一套OA自动化办公系统源码最大的价值不是里面的代码能直接用而是它把“组织架构、审批流、消息通知、报表导出”这条企业软件的核心链路完整演了一遍。我接手过不少客户买来的OA源码最后能真正稳定跑两年的都不是因为代码写得多好而是因为有人在认真维护它——把流程和业务对齐把数据权限梳理清楚把不靠谱的初始化数据清理干净。完成这套源码从“能跑”到“好用”的改造我个人最大的教训是永远要先还原数据库初始数据和菜单权限再去动业务代码否则你改了三行Java排查了一个星期最后发现是数据的问题。如果你正准备投入这套源码先把它在本地跑通跑通之后再决定改哪里。希望帮到你。本文还有配套的精品资源点击获取
简介面向需要搭建办公自动化系统的Java开发者这份基于Spring Boot、Maven与MySQL的OA系统源码覆盖日常办公管理核心功能可帮助理解企业级项目从分层架构到数据持久化的完整落地路径。压缩包共1031个文件以237个Java源文件为主干配合152个FreeMarker模板、85个JS、56个CSS与39个HTML组成前端交互层另含SQL数据库脚本、properties配置及大量png/gif示意图片整体仅5.49MB结构紧凑便于按模块检索其中SQL脚本可直接导入MySQL使用。目前已有1899人学习适合正在研究Spring Boot整合或需要快速搭建OA原型的开发者。通过源码可掌握文件上传接口、后台管理页面动态渲染及多表关联查询等关键实现还能参考asp/php等辅助脚本了解跨语言接口写法配合完整目录组织能有效支撑二次开发与功能扩展。1. 一套Java写的OA自动化办公系统源码到底能不能拿来就用手头有一套“Java开发OA自动化办公系统源码.zip”不是每个打开压缩包的人都能把它跑起来。我见过太多人解压之后对着application.yml、pom.xml和一堆看不懂的数据库脚本发呆然后去搜索引擎里翻“泛微oa e10 初始密码”“致远oa管理员培训”这类词——那不是在看源码那是在找后悔药。这个标题真正要回答的问题是这套源码是什么技术栈、能不能在本地跑通、业务功能做到什么程度、二次开发要动哪些地方。适合的人有两类一类是Java初学者想借一套完整系统搞懂企业级项目的模块划分另一类是中小团队想快速搭一个内部办公系统不想从零写组织架构、审批流和权限模型。这篇文章会从工程视角把它拆开给出能直接复现的步骤、参数和坑。2. 拆解这套OA源码之前先搞清技术选型为什么这么走2.1 从包名和依赖入手判断项目的真实结构拿到OA自动化办公系统源码.zip我第一件事不是看代码而是看根目录。通常一个规范的Maven项目会带着pom.xml、src/main/java、src/main/resources和sql或db目录。如果压缩包里连pom.xml都没有说明它可能是Eclipse工程或者远古时代的Java Web项目——那种带着.classpath和.project文件的古董跑起来的成本会高一个量级。常见做法是这类OA源码会用Spring Boot作为底座因为它的自动配置能极大减少XML配置。到了2024年往后还在用SSHStruts2 Spring Hibernate结构的OA源码不太多了即使是老项目多数也完成了向Spring Boot的迁移。我一般会先看pom.xml里的依赖树确认三件事主框架版本是Spring Boot 2.x还是3.x、持久层用的是MyBatis还是MyBatis-Plus还是JPA、权限方案是Spring Security还是Shiro还是自己写拦截器。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency /dependencies这是一套很典型的现代OA技术底座。选Spring Boot是因为它天然适合这种“模块多、配置杂、要快速集成”的企业系统选MyBatis-Plus是因为OA里的报表统计、多条件分页查询非常多单表CRUD用它的Wrapper能少写一半样板代码选Spring Security则是因为OA必须面对组织架构、菜单权限、数据权限三层的复杂控制Shiro虽轻但到数据级权限就吃力了。版本上2.7.18是Spring Boot 2.x的最后一个社区维护版稳定坑少JDK 8到17都能跑适合作为这种源码的底座。如果发现这个项目的Spring Boot版本是3.x那就要注意JDK必须17往上且javax.servlet包会变成jakarta.servlet导入老代码时需要批量替换。这一条最容易让人第一次启动就翻车。2.2 看清“自动化办公”在Java源码里具体指什么“自动化办公系统”是一个很宽泛的词。搜索热词里同时出现“泛微OA”“致远OA”“蓝凌OA”说明很多人印象中的OA是这些商业产品的样子——有门户、有流程引擎、有知识库。但一套被称为“源码”的Java OA项目不可能达到商业产品的高度它的“自动化”通常落在三个具体点上。第一是审批流的自动化请假、报销、用章申请从发起到归档全走线上第二是消息提醒的自动化待办、催办、抄送通过站内信或邮件去触达第三是数据汇总的自动化考勤、日报、项目工时自动汇成报表。判断一套OA源码值不值得跑就看这三块是不是真的实现了而不是只有一张登录页和一两个CRUD。我在打开源码后一般会先搜索controller包里的接口数量如果整个系统只有login、user、dept这几个入口那它就是个壳不值得往下看。自动化办公系统的核心价值是“把线下流程搬到线上并留下痕迹”所以源码里最值得读的是workflow模块和message模块。工作流模块的实体关系、消息模块的推送时机才是这套源码的含金量所在。后面会专门拆工作流的部分。2.3 数据库脚本是整个源码能否复现的分水岭解压之后先找.sql文件放在哪个目录然后用数据库客户端跑一遍建表脚本。这套系统的表结构通常包括sys_user、sys_role、sys_menu、sys_dept、oa_leave、oa_reimburse、oa_notice、oa_message、act_*这些前缀的表——如果出现act_前缀说明工作流引擎用的是Activiti或Flowable那种情况源码的技术深度会高一些踩坑点也多一些。-- 标准的OA用户表结构注意这里省略了字段注释之外的部分 CREATE TABLE sys_user ( user_id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 用户ID, dept_id bigint(20) DEFAULT NULL COMMENT 部门ID, user_name varchar(30) NOT NULL COMMENT 登录账号, nick_name varchar(30) NOT NULL COMMENT 用户昵称, email varchar(50) DEFAULT COMMENT 邮箱, phonenumber varchar(11) DEFAULT COMMENT 手机号码, sex char(1) DEFAULT 0 COMMENT 性别, avatar varchar(100) DEFAULT COMMENT 头像地址, password varchar(100) DEFAULT COMMENT 密码, status char(1) DEFAULT 0 COMMENT 帐号状态0正常 1停用, del_flag char(1) DEFAULT 0 COMMENT 删除标志0存在 2删除, create_time datetime DEFAULT NULL COMMENT 创建时间, PRIMARY KEY (user_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT用户信息表;注意两个点。第一是字符集老源码经常是utf8而不是utf8mb4如果系统里要录入Emoji比如企业微信昵称utf8会报“Incorrect string value”错误跑核心脚本前统一改成utf8mb4能省掉后面一堆编码问题。第二是ENGINEInnoDB如果脚本里出现MyISAM意味着这套源码当年没考虑事务报销审批这种写多个表的场景会有一致性隐患。跑脚本前我习惯把sql_mode里的ONLY_FULL_GROUP_BY去掉因为很多老OA的统计SQL在严格模式下直接报错这是最常见的数据库脚本翻车点。3. 在本地把OA源码跑起来最小可行启动流程3.1 前置环境JDK、Maven、MySQL的版本怎么配先列一套我验证这类OA源码时用的环境组合再说明每个组件的边界。JDK用1.8即8u202之后的版本Maven用3.6.3或3.8.xMySQL用5.7或8.0Redis如果有集成就用5.x以上。这套组合的兼容性最广能覆盖绝大多数Spring Boot 2.x时代的OA源码。如果源码里明确写了Spring Boot 3.x或者Spring Cloud Alibaba那JDK必须切到17Maven用3.9.x。不要幻想用JDK 17跑老项目java.lang.NoClassDefFoundError会教你做人。在Windows上配置环境变量时注意JAVA_HOME不要再指向C:\Program Files\Java\jdk1.8.0_301\jre那是安装时容易犯的错——必须指到JDK的根目录否则IDE和命令行看到的是不同的运行时。# Linux / macOS 下用 sdkman 管理 JDK 版本切换 sdk install java 8.0.392-tem sdk use java 8.0.392-tem # 验证当前环境 java -version mvn -version mysql --version这三个命令的输出决定了后续所有步骤是否值得进行。我见过有人卡在mvn -version报Unsupported major.minor version 52.0——那是因为Maven本身需要JDK 7以上而JAVA_HOME指向了JRE。这类问题看起来低级但在给客户部署时出现频率极高判断环境时务必直接看命令回显不要相信系统设置面板里的字符串。3.2 初始化数据库并修正连接配置找到源码包里sql或db目录下的主脚本通常是oa_init.sql或oa_full.sql。用命令行或Navicat执行之前先建一个空库库名建议和脚本里的保持一致避免去改脚本里的USE语句。# 登录 MySQL 后执行 CREATE DATABASE oa_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE oa_system; SOURCE /path/to/your/oa_init.sql; # 验证表是否建全 SHOW TABLES;执行完SHOW TABLES应该能看到几十张表数量太少就要怀疑脚本是不是只建了核心表初始化数据尤其是部门树、菜单表、角色表有没有成功插入。sys_menu表通常有几百行初始数据如果只有几条登录进去会看到一片空白菜单。源码里若带有data.sql和schema.sql这种Spring Boot惯用文件名Spring Boot会在启动时自动执行它们但多数OA源码不会这么设计而是要求手动导入主脚本。之后改application-druid.yml或application.yml里的数据源。重点检查username、password、url三个字段URL里要带上useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai不然时间字段和中文会出现灵异现象。还要确认driverClassName是com.mysql.cj.jdbc.Driver而非com.mysql.jdbc.Driver后者只在老驱动里有效在MySQL 8.0连接器下会直接启动失败。spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driverClassName: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/oa_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_mysql_password initialSize: 5 minIdle: 5 maxActive: 20这些参数里maxActive20是中小型OA的合理选择。OA系统的并发特征不是高QPS而是大量长连接和短事务连接池太小会导致高峰期报CannotGetJdbcConnectionException太大则浪费MySQL的连接数上限。initialSize和minIdle保持5就够了没必要设成100。3.3 启动入口和第一个登录请求多数OA源码的主类是com.oa.OaApplication或者OaApplication.java用IDE直接运行或者在项目根目录执行mvn spring-boot:run。看到Started OaApplication日志后打开浏览器访问http://localhost:8080。如果端口不是8080检查application.yml里的server.port。# 编译并启动跳过测试避免 test 阶段报环境相关的错 mvn clean package -DskipTests java -jar target/oa-system-1.0.0.jar第一次启动大概率会遇到两个问题。一个是Redis连不上OA源码喜欢把验证码、Token缓存到Redis启动时连不上会直接报错退出——如果源码不强依赖Redis可以在配置里注释掉Redis的自动配置或者在本地起一个带默认密码的空实例。另一个是静态资源路径错乱登录页能出来但验证码图片不显示通常是Kaptcha组件的字体文件在Linux上找不到往服务器/usr/share/fonts里丢一个中文字体就能解决。登录接口返回的Token决定了后续所有操作能否继续。用命令行验证一下接口是否通才能确定前后端联调的边界在哪里。curl -X POST http://localhost:8080/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123}如果返回JSON里带有token字段说明认证链路是通的。之后把这段Token放到Authorization: Bearer token请求头里再访问/system/user/list之类的接口测试数据权限。很多读者在这步直接打开浏览器登录页报错就认为是源码不行——其实一半以上的启动失败都出在数据库版本或Redis环境上跟代码本身的逻辑无关。4. OA自动化办公系统的三大核心模块怎么改、参数怎么调4.1 组织架构与权限模型树表结构怎么设计才不踩坑OA和普通管理系统最大的区别在组织架构。sys_dept表以parent_id和ancestors两个字段维护树结构ancestors存的是从根到当前节点的ID路径用逗号分隔。这个设计在查询“某个部门下所有子部门的人”时非常高效一条LIKE就能搞定但在数据量超过几千条时ancestors LIKE %xx%会全表扫。改法也不难维护一张闭包表或者在业务查询里改成先查子树再查人。-- 典型OA查询查某个部门及其所有子部门下的人员 SELECT u.user_id, u.user_name, d.dept_name FROM sys_user u JOIN sys_dept d ON u.dept_id d.dept_id WHERE d.ancestors LIKE CONCAT(%,, #{deptId}, ,%) OR d.dept_id #{deptId};权限方面这套源码如果基于Spring Security会有一个PreAuthorize注解标在Controller上。它的表达式通常是hasPermi(system:user:add)对应sys_menu表里的perms列。二次开发时新增一个按钮权限流程是在菜单表插入一行记录再给角色关联上而不是去改Java代码里的硬编码。如果源码里出现大量user.getRoleId()这种手写判断说明它的权限管理还停留在“能登录就行”的阶段数据级权限比如部门经理只看本部门数据大概率没做那种情况就别指望扩展了。4.2 审批流的“自动化”到底自动在哪状态机与工作流引擎“自动化办公系统”的含金量集中在审批流。商业OA泛微、致远靠的是自研流程引擎能画节点、能配条件。源码型项目一般只有两种实现一种是自己写状态机用status字段加if/else推进另一种集成Activiti或Flowable走BPMN 2.0标准。前者轻量、好改、适合中小团队后者流程可视化但学习成本高、和业务代码耦合时容易翻车。看清源码用哪种决定了后续所有二次开发的姿势。如果是自研状态机核心逻辑通常会集中在WorkflowService里。一个请假申请的流转大概长这样public void approve(Long taskId, Integer userId, Boolean pass, String comment) { WorkflowTask task workflowTaskMapper.selectById(taskId); // 核心根据当前节点决定下一个节点 if (task.getStatus() 1) { // 1 - 部门经理审批 if (pass) { task.setStatus(2); task.setCurrentApprover(deptManagerId(task.getApplicantId())); } else { task.setStatus(-1); } } else if (task.getStatus() 2) { // 2 - 人事归档 if (pass) { task.setStatus(3); } else { task.setStatus(-1); } } task.setUpdateTime(LocalDateTime.now()); workflowTaskMapper.updateById(task); // 审批通过后写消息触发待办通知 messageService.notify(task); }这段代码的逻辑说明状态机以status明确定义当前审批所处节点每一步审批都判断当前状态和操作结果然后推进到新节点或驳回终态。currentApprover字段存的是当前节点审批人的用户ID用来支撑待办查询。messageService.notify(task)是自动化体验的关键——审批完成后下一节点的人要实时收到待办提醒这一步没做系统立刻退回“手工时代”。参数设计上有两个地方必须改。一个是驳回的分类真正好用的OA至少要区分“驳回修改”和“终止流程”前者回到申请人草稿状态后者直接归档——上面的代码把两者全打成-1实际业务里这会造成用户困惑。另一个是审批人设置deptManagerId从哪来sys_dept表里如果没存leader字段就得去sys_user表按dept_id和role_id联合查这决定了后续加“指定审批人”功能时要动多少代码。4.3 消息与待办的推送明明发出去为何读不到消息模块最常见的坑是“待办数量不对”和“已读未读状态错乱”。根源在于OA系统里消息的接收人经常是角色或部门而非单一用户——如果用send_to_user_id存单用户那“发给全体财务”就得循环插入几百条消息性能和设计都不合适。正确做法是拆两张表oa_message存消息本体oa_message_receiver存接收人、已读状态、阅读时间。这类源码若是单表设计可以按这个思路补一张关联表来解耦。另一个高频坑是消息与站内信的会话。OA源码里经常把“审批待办”和“站内通知”混在一张表里导致已办的流程在待办列表里不清空用户每天被无效提醒轰炸。合理的做法是在oa_message表加biz_type字段区分TODO和NOTICE查询时用status和biz_type联合过滤。如果源码里没有这个字段手工补一个并做一次数据订正就能显著改善使用体验。配置层面如果消息要推到企业微信或钉钉通常需要在application.yml里配置Webhook地址和加签密钥。这些内容在源码里会以appId、secret等形似默认值的占位符存在上线前必须替换成真实值且不要把密钥提交到Git仓库。注意企业微信机器人有每分钟最多20条的消息频率限制OA系统“待办促办”功能上线后很容易触发这个限制消息模块一定要做队列削峰否则会出现“越催越没信”的尴尬。4.4 报表与导出POI操作Word/Excel的注意点OA系统的报表导出逃不开Apache POI。搜索热词里有“java poi word能生成图表吗”答案是能但直接生成图表代码量不小且样式难以控制。更稳妥的落地方式是用模板把带${}占位符的docx或xlsx文件放resources目录运行时用POI填充数据后输出。这样图表、水印、页眉页脚全部提前在Office里画好Java代码只负责填值不会出现“代码生成的图表丑到不敢发给领导”的场面。// 基于 XWPFDocument 做 Word 导出填充模板变量 try (FileInputStream fis new FileInputStream(template/leave.docx); XWPFDocument doc new XWPFDocument(fis)) { // 遍历段落替换 ${name} 占位符 for (XWPFParagraph para : doc.getParagraphs()) { ListXWPFRun runs para.getRuns(); for (XWPFRun run : runs) { String text run.getText(0); if (text ! null text.contains(${name})) { run.setText(text.replace(${name}, leave.getUserName()), 0); } } } try (FileOutputStream out new FileOutputStream(output/leave_ leave.getId() .docx)) { doc.write(out); } }这段代码的说明XWPFParagraph代表Word中的一个段落XWPFRun是段落里带同一格式的片段。替换时的关键点是如果占位符被Office拆分到多个run里Word经常干这事上面这种简单的replace就会漏掉——稳妥做法是先合并同段落的run文本再替换或者用TextBody的getText/setText整段操作。导出Excel时注意SXSSFWorkbook只适合纯数据导出有复杂表头合并样式时XSSFWorkbook才稳定但后者的对象不释放会引起内存溢出大批量导出一定要分页查询和批量写行。5. 避坑手册我在部署Java OA源码时踩过的五条实际坑5.1 启动报错“Failed to configure a DataSource”现象Spring Boot启动时直接红字报错提示无法配置数据源且SpringBootApplication注解旁没有任何排除项。原因项目里引入了spring-boot-starter-data-jpa或Druid依赖但application.yml里的数据源配置没有被加载。最常出现在修改过配置文件名之后——比如把application-dev.yml改成了application.yml但里面的缩进不对YAML解析失败导致连接信息真空。解决先跑一下mvn spring-boot:run看全量日志前20行确认加载的是哪个配置文件再用IDEA的Spring面板看Environment标签里spring.datasource.url是否有值。如果源码里有多个application-*.yml要留意spring.profiles.active项被设成了什么。5.2 登录验证码永远校验失败现象验证码图片能显示但输入“正确”的字符总是报错。原因多数OA用Kaptcha生成验证码并把答案放在Redis或Session里。如果用Redis存验证码且Redis宕过或清空过key那么旧验证码全部失效如果是Session模式那么前端请求验证码接口和登录接口的Cookie没有保持一致——常见于前后端分离前端代理把Cookie路径搞丢了。解决方式查看KaptchaController生成验证码时写入的是Redis还是Session然后顺着请求链路确认浏览器发出的Cookie头有没有带JSESSIONID或TOKEN。另外部分源码对验证码做了“一次性校验”前端先提交了验证码、被拦截器拦下再重试一次第二次必然失败——这种情况把页面刷新重来即可不算代码Bug。5.3 菜单树出现重复节点越查越多现象登录后系统菜单偶尔多出几条重复项刷新后恢复再刷新又重复。原因sys_menu表到sys_role_menu的关联表里出现了重复关联且菜单查询SQL里用了LEFT JOIN没加DISTINCT。这属于初始化数据脚本自带的问题并非运行时产生。解决方法是先查重复关联然后删掉冗余行并给role_id, menu_id加唯一索引兜底。-- 找出重复的角色-菜单关联 SELECT role_id, menu_id, COUNT(*) FROM sys_role_menu GROUP BY role_id, menu_id HAVING COUNT(*) 1; -- 删除重复行保留最小id那行 DELETE a FROM sys_role_menu a JOIN sys_role_menu b ON a.role_id b.role_id AND a.menu_id b.menu_id WHERE a.id b.id;执行后顺手补一个唯一索引防止后续操作再次引入重复数据。这个问题不严重但会直接影响用户信任度——系统管理员看到菜单乱跳会觉得整个系统都不稳定。5.4 审批流卡死状态被改但流程不推给下一人现象审批人点击“同意”后界面提示成功但下一节点的人刷新列表看不到待办。原因这类源码的逻辑最常见的是审批操作里只更新了主表status字段没有生成oa_message记录或者消息表里的receiver_id写错。解决方式在approve(...)方法调用后立刻查询oa_message表里是否多了一条待办记录。如果为零多半是messageService.notify(task)内部根据currentApprover查用户时拿到空值要往前排查deptManagerId。还有一个隐蔽点Transactional事务没提交消息查询用了READ_COMMITTED隔离级别在同一连接里查不到未提交数据。这种时候把消息发送放到事务提交后的TransactionSynchronizationManager.registerSynchronization里最稳妥。5.5 导出Excel中文文件名乱码现象下载的报表文件名是“%E8%80%83%E5%8B%A4.xlsx”或者文件名正常但打开后中文内容乱码。原因文件名乱码是响应头Content-Disposition没有做URLEncoder.encode内容乱码则是Excel模板本身编码问题。解决文件名部分先URLEncoder.encode(fileName, UTF-8)再拼到Content-Disposition里内容乱码要看模板里的字体嵌没嵌入。POI生成的文件乱码几乎总是字体缺失导致的——目标机器上没装中文字体时Excel会用默认字体渲染成乱码或方框。// 正确设置下载文件名兼容主流浏览器 String encodedFileName URLEncoder.encode(fileName, StandardCharsets.UTF_8.toString()) .replaceAll(\\, %20); response.setHeader(Content-Disposition, attachment; filename*UTF-8 encodedFileName); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet);这段代码说明了两个关键参数filename*带UTF-8前缀是RFC 5987标准写法用于告诉浏览器文件名编码方式replaceAll(\\, %20)是为了处理URLEncoder会把空格编码成加号的问题——不替换的话文件名里的空格会在浏览器里显示成加号虽然不影响下载但看着难受。6. 把这套OA源码推向生产的最后一步性能验证与发布技巧源码能在本地跑通只能算第一步真正决定它能不能作为团队内部工具长期运行的是并发能力和部署方式。我习惯上线前做一个轻量压测用Apache JMeter模拟30个用户同时提交请假单、50个用户同时查询待办列表观察/workflow/task/list这个接口的响应时间。若P95超过500ms优先查数据库慢查询而不是去调代码——OA的逻辑基本是单表查询加关联最常见的慢查询出在ancestors LIKE和未经索引的create_time排序上。部署方式上不要用java -jar加nohup的单体裸奔方式。即使是中小团队也建议用systemd管理Java进程让它异常退出时自动拉起。同时要配置JVM参数堆内存根据服务器物理内存设定在-Xms1g -Xmx2g之间——OA系统不是高并发应用堆给太大反而会造成GC长时间停顿。编译发布时还有一个容易漏掉的细节源码包里的resources目录下可能含有application-prod.yml、application-test.yml这些文件打包时会把全套配置都带进jar。如果不希望生产配置泄露在工件里打包时单独指定profile过滤。这一步在商业项目里很常见源码项目里也应当保留这个习惯。最后我想说的是一套OA自动化办公系统源码最大的价值不是里面的代码能直接用而是它把“组织架构、审批流、消息通知、报表导出”这条企业软件的核心链路完整演了一遍。我接手过不少客户买来的OA源码最后能真正稳定跑两年的都不是因为代码写得多好而是因为有人在认真维护它——把流程和业务对齐把数据权限梳理清楚把不靠谱的初始化数据清理干净。完成这套源码从“能跑”到“好用”的改造我个人最大的教训是永远要先还原数据库初始数据和菜单权限再去动业务代码否则你改了三行Java排查了一个星期最后发现是数据的问题。如果你正准备投入这套源码先把它在本地跑通跑通之后再决定改哪里。希望帮到你。本文还有配套的精品资源点击获取
