做Java后台开发这些年，我接触过不少企业项目，OA管理系统绝对算是最典型、最能锻炼人的一类。它不像电商那样高并发，也不像推荐系统那样堆算法，但胜在业务链路长、角色权限细、流程节点多，几乎把企业日常运转的方方面面都含进来了。这次要聊的这个项目——基于Spring Boot的Java企业OA管理系统（编号11801），就是一套从零搭建、可以真正跑起来支撑日常办公的系统。它涵括用户权限、审批流、考勤请假、公告公文、文件管理等核心模块，技术上踩稳了Spring Boot的一整套生态。如果你刚好学完Java基础、想找一个有完整业务闭环的项目练手，或者你们公司内部正缺一套能用的办公管理工具，这篇文章应该能帮你省下不少弯路。
有人可能会问，市面上的开源OA不少，泛微、致远、通达这些也都很成熟，为什么还要自己搭一套？我的看法是：大厂OA的开源版本要么太重，光部署就要研究半天；要么很多高级功能是闭源的，你想要就得付费。自己基于Spring Boot搭一套轻量OA，灵活可控，核心逻辑全部掌握在自己手里，后续想扩展什么模块都是自己的节奏。这篇文章不打算只丢给你一堆代码，而是把它背后设计上的考虑、踩过的坑、排查过的疑难问题都摊开讲，让你不只是会复制粘贴，而是真正知道每一步为什么这么做。
1. 项目定位与整体方案设计
1.1 核心需求解析：OA系统到底要解决什么问题
很多人把OA简单理解成“请假审批系统”，这个认知其实窄了。企业办公自动化的本质，是把内部杂乱无章的线下流程搬到线上，做成有规则、有记录、有追溯的闭环。这背后对应的是四个核心诉求。
第一个诉求是身份统一管理。公司里有几十上百号员工，每个人在系统里得有一个账号，账号要跟着人走，人离职了账号要能停用，不能留下安全隐患。第二个诉求是权限精细控制。一个普通员工和部门经理、公司高管，在系统里能看到的菜单、能操作的功能、能审批的流程完全不一样。权限要是做粗糙了，要么是员工误入了管理界面，要么是领导找不到审批入口，两头都难受。第三个诉求是流程规范化。请假、报销、采购申请，每一步该谁审、审不过怎么办、要不要会签，这些规则得写进系统里，不能靠口头沟通。第四个诉求是数据留痕可追溯。谁在什么时间提交了什么申请，审批意见是什么，全部要有日志记录。企业做内控、做审计的时候，这些数据就是最有力的凭证。
我把这四条整理成表格，开发的时候就能对应到具体的功能和数据表设计上。
| 核心诉求 | 业务场景 | 对应功能模块 |
|---|---|---|
| 身份统一管理 | 员工入职、转岗、离职 | 用户管理、部门管理 |
| 权限精细控制 | 不同角色看到不同菜单和操作 | RBAC权限模型、菜单管理 |
| 流程规范化 | 请假、报销、用章等审批 | 工作流引擎、审批中心 |
| 数据留痕可追溯 | 审批记录、操作日志、公文流转 | 操作日志、登录日志、审批记录 |
这套11801项目，就是我基于上面四个诉求来划分模块的。它不是凭空设计的菜单堆砌，而是每一个功能都有明确的业务定位和用户群体。
1.2 技术选型与理由：为什么是这些组件
技术选型是项目动工前最关键的决策。我的选择很明确：Spring Boot 2.7.x + MyBatis Plus 3.5.x + MySQL 8.0 + Redis + Spring Security + JWT，前端用Vue 3 + Element Plus做前后端分离。这套组合在中小企业里的接受度非常高，而且每一环都有它不可替代的理由。
Spring Boot自不必多说，它最大的价值在于把Spring家族的整合成本降到了最低。以前搭一个SSM项目，要写一堆XML配置，光配置数据源、事务管理器、MyBatis的Mapper扫描就要折腾小半天。Spring Boot的自动装配把这些都包办掉了，配置文件从XML变成了简洁的application.yml，开发效率直接翻倍。这也是为什么现在Java招聘市场上Spring Boot几乎是必问项，你在任何Java面试里都躲不开Spring Boot的自动装配原理这个话题。
持久层我选了MyBatis Plus而不是原生MyBatis，理由很直接：单表CRUD不用手写SQL了，BaseMapper接口直接把insert、update、selectById这些方法给你备好，光这一点就省了至少三分之一的数据层代码。同时它还提供了逻辑删除、自动填充、分页插件这些实用的功能，几乎是为业务系统量身定制的。MyBatis Plus虽然在复杂多表查询上不如MyBatis灵活，但我在项目里所有复杂的统计类SQL都是自己写在XML里的，两者互补，刚刚好。
缓存方面引入Redis，用途有三个：一是验证码存储，验证码有实效性，Redis天然支持过期时间；二是登录用户token的黑名单；三是数据字典、菜单列表这类变化少、读取频繁的数据。MySQL的InnoDB虽然也有查询缓存，但和Redis比还是差远了，这种高频只读数据的缓存放在Redis里收益最高。
1.3 系统模块划分与架构分层
这套OA系统的功能模块划分不复杂，核心是业务模块加系统管理模块两大类。
系统管理模块包含：用户管理、部门管理、角色管理、菜单管理、操作日志、登录日志。这些是常规的后台管理功能，也是权限模型的地基。业务模块包含：流程审批（请假、报销、采购申请）、考勤管理、通知公告、公文管理、会议管理、日程管理、文件中心。流程审批是OA的心脏，考勤和请假是使用频率最高的两个功能，文件中心解决的是企业内部文件的存储和分享问题。
架构上，项目按照经典的分层结构来组织，Controller层只负责接收参数和返回结果，不写业务逻辑；Service层是业务核心，处理所有业务规则和事务控制；Mapper层负责数据库交互。实体对象拆分成了VO、DTO、Entity三层，很多新手不理解为什么要这样做，举一个场景你就明白了：查询用户列表时，数据库里的User表有密码字段，但接口不能把密码返回给前端，如果你直接用Entity去承接前端请求或返回响应，要么就是密码泄露，要么就是接收参数时被恶意塞入额外字段。用VO专门定义“接口层该返回什么”，用DTO定义“接口层该接收什么”，各司其职，安全性和维护性都能保证。
2. 核心功能模块设计与实现
2.1 用户认证与权限管理：Spring Security + JWT如何配合
登录认证是我在OA系统里第一个动手实现的模块。很多新手一上来就写一个登录接口，成功就返回一个用户对象，失败就返回错误信息，看起来功能做好了，实际上漏洞不少，最大的问题是登录之后没法判断“你是谁”。
我选用Spring Security + JWT这套方案来解决认证和授权问题。登录流程是这样：用户提交用户名和密码，后端校验通过后，用用户的id和角色信息生成一个JWT token返回给前端，前端在后续请求的Header里带上这个token。后端有一个OncePerRequestFilter，每一次请求进来都会先经过这个过滤器，解析token、校验签名和过期时间、把用户信息放进SecurityContext里，这样Spring Security就能在后续的权限判断中使用当前用户信息了。
JWT的核心价值在于无状态。服务器不用存session，token自包含用户信息，这在前后端分离、多端登录的场景下特别合适。不过JWT也怕泄露，所以我额外在Redis里维护了一个token过期策略，用户修改密码或强制下线时，会把旧的token拉黑，保证安全性。
权限模型我采用了标准的RBAC（基于角色的访问控制）五表模型：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。菜单表里存的不只是菜单项，还包括每一个页面按钮的权限标识，比如“sys:user:add”、“oa:leave:approve”。后端在需要权限控制的接口上加上@PreAuthorize("hasAuthority('sys:user:add')")注解，没有对应权限的请求会被Spring Security拦截，返回403。
2.2 工作流审批模块：不建议一上来就上Flowable
工作流是OA系统里技术含量最高的模块。很多人在设计阶段就会纠结要不要用Flowable、Activiti这类重型工作流引擎。我的建议：如果项目规模在100人以内的企业内用，不要一上来就上Flowable。
Flowable的功能确实强大，支持BPMN2.0标准，流程设计器、会签、或签、条件分支、驳回、流程版本管理，什么都有。但代价是极高的学习成本和系统复杂度。光Flowable自身的表就有七八十张，而且它的API体系、监听器机制、流程引擎与业务表的关联方式，对新手上手是很大的负担。很多时候你只是想实现“员工请假 -> 部门经理审批 -> 人事备案”这样一个简单流程，用Flowable反而有种杀鸡用牛刀的感觉。
我在这套系统里采用了自己封装的一套轻量级审批引擎，核心设计是两张表：审批流程定义表和审批记录表。审批流程定义表配置一个审批类型对应的审批节点顺序，例如请假流程是“发起人提交 -> 直接上级审批 -> 人事复核”。审批记录表记录每一次实际的审批流转，谁在什么时候提交、谁批了、审批意见是什么。每个节点审批通过后，自动把流程推进到下一个节点，同时给下一个审批人发送待办通知。
这样设计的好处是流程逻辑完全在自己的掌控之中，出了问题可以直接看代码排查，业务人员也能通过后台界面灵活配置审批链。如果后续业务量真的增长了，需要条件分支、会签这些复杂能力，再考虑在保留业务表的基础上，把流转引擎替换为Flowable也不迟，这也是架构上预留的扩展余地。
2.3 考勤与请假管理模块的实现细节
考勤模块是给HR和普通员工用的。员工每天上班打卡、下班打卡，HR可以查看考勤统计报表。打卡功能我设计成了两个入口：PC端手动打卡和移动端定位打卡。移动端定位打卡调用了地图接口，判断用户当前坐标和公司坐标之间的距离，误差小于300米才算有效打卡，防止有人在家里打卡糊弄考勤。
考勤统计是每月底生成一份月度汇总，包括应出勤天数、实际出勤天数、迟到次数、早退次数、缺勤天数、请假天数。这件事如果让HR用Excel手工做，每个月至少要忙一整天，但系统自动生成报表后，只需要点一下按钮，几秒钟就出来了。报表的核心SQL是按月和用户分组，对打卡记录表做聚合统计，这部分我写在MyBatis的XML文件里，因为涉及到多表关联和条件统计，用SQL直接写比用MP的Wrapper更清晰。
请假管理和审批流程是联动的。员工提交请假申请时，必须选择请假类型（事假、病假、年假、调休）、起止时间和请假事由。系统会自动计算请假天数，并在提交时校验年假余额是否充足。审批通过后，系统自动扣减年假余额，同时在考勤统计中把请假时段标记为“请假”，避免既算请假又算缺勤。
这里有一个容易被忽略的点：请假天数的计算。按自然日算还是按工作日算，结果差别很大。我的设计是默认按工作日计算，节假日自动跳过，这个逻辑用Java的LocalDate循环判断再配合一个节假日配置表来实现。HR可以在后台维护每年的法定节假日，系统计算请假天数时就会自动排除掉这些日期。
2.4 通知公告与文件中心的设计与实现
通知公告模块解决的是企业信息传达的问题。管理员发布公告后，所有员工登录系统就能在首页看到。我加了一个“已读回执”功能：公告详情页记录每个用户的首次阅读时间，这样发布人就能知道这个公告到底有多少人看了、哪些人还没看。这个功能在春节放假通知、制度发布这种场景下特别实用，HR不用再挨个在群里问“收到请回复”。
文件中心解决的是部门和公司级文件共享的问题。存储方案上我没有直接用云厂商的OSS，而是先做了本地磁盘存储，后续可以平滑切换到MinIO或OSS。原因是企业内部OA的文件量级通常不大，本地存储完全够用，而且不产生额外的云服务费用。如果你后续确实要换OSS，只需要把文件存储的Service接口实现类替换一下，存储逻辑对上层是无感知的。
文件上传还有一个要注意的细节：文件重名问题。我采用UUID重命名文件，但为了用户下载时能看到原始文件名，文件名的映射关系保存到了数据库的文件记录表里，用户下载时通过接口将UUID对应的原始文件名返回给浏览器。如果你直接拿用户上传的文件名保存到磁盘，大概率会遇到中文乱码、特殊字符、重名覆盖等各种问题，这一条也是我在项目上线后被坑过一次才回头补上的。
3. 关键实现细节与实操要点
3.1 统一返回结果与全局异常处理
在后台接口开发中，统一返回结果是一个必须从第一个接口就建立起来的规范。我定义了一个Result 泛型类，包含code、message、data三个字段。code为200表示成功，其他值表示失败或业务异常。所有接口的返回值都是Result ，前端axios封装里统一处理，code为200就直接取data渲染页面，不为200就弹出message提示错误信息。
比统一返回结果更重要的是全局异常处理。如果没有全局异常处理，代码里任何一处未捕获的异常都会导致Spring Boot返回一个默认的错误页面或堆栈信息直接暴露给前端，既不友好也不安全。
我用@RestControllerAdvice注解写了一个全局异常处理器，把异常分为三层来处理。第一层是业务异常，例如请假天数超过余额、审批人未配置、上传文件过大等，我会在Service层主动抛出BusinessException，处理器捕获后返回业务错误码和提示信息。第二层是参数校验异常，例如入参为空、格式错误，返回400和具体的字段错误信息。第三层是系统异常，例如数据库连接失败、空指针异常，统一返回“系统繁忙，请稍后重试”，同时把完整的堆栈打到日志文件里，方便排查。
这样设计的好处非常明显：前端接到的永远是一个结构统一、信息明确的JSON，后端也不用在每个方法里写try-catch，代码干净很多。
3.2 MyBatis Plus的增强配置与使用技巧
MyBatis Plus虽然用起来简单，但如果配置不当，很容易埋坑。有两个配置我建议一定要打开。
第一个是逻辑删除配置。企业的用户数据、审批数据不能物理删除，万一误删了没法恢复。我在application.yml里配置了逻辑删除的全局配置，对应的实体字段加上@TableLogic注解，这样调用deleteById方法时，实际执行的是update语句把deleted字段置为1，查询时所有MP的自动SQL都会自动加上deleted=0的条件，在给用户的删除和查询效果上，像物理删除一样省心。
第二个是字段自动填充。每张业务表都有create_time、update_time两个字段，手动在每次insert和update时都写一遍太啰嗦。我实现了一个MetaObjectHandler接口，在insert时自动填充create_time和update_time为当前时间，在update时自动更新update_time。这样实体类里这两个字段加个@TableField(fill = FieldFill.INSERT)或@TableField(fill = FieldFill.INSERT_UPDATE)注解，就不用再手工赋值了。
分页插件的使用也需要特别说明。PaginationInnerInterceptor的数据库类型要设置成和你的数据库一致，例如DbType.MYSQL。很多人不设置或设置错了，分页SQL会生成错误，最典型的问题是查出全表数据而不是指定页码的数据。这个细节我在开发的时候就遇到过，排查了快一个小时才发现是数据库类型没配。
3.3 Redis缓存策略：验证码、用户信息与数据字典
Redis在这个项目里的应用，不是简单的拿来存数据，而是有明确的策略。
验证码存储是最典型的应用。登录页的验证码生成后，我以uuid为key、验证码文本为value存入Redis，过期时间为5分钟。用户提交登录时，带着uuid和验证码来校验，后端从Redis里取出来比对，比对了就删除这个key，保证一个验证码只能用一次。使用Redis的过期机制，天然解决了验证码的生命周期管理问题，比存session再定时清理省事得多。
用户菜单缓存也是提升性能的关键。一个用户登录后，他有哪些菜单、哪些按钮权限，这组数据是相对固定的，只有在管理员改了角色分配后才会变化。如果每次请求都去数据库查一遍菜单表、关联表、再组装成树形结构，数据库压力大，响应也慢。我的做法是用户登录成功后，把该用户的权限标识列表缓存到Redis里，key为login:user:permissions:{userId}，过期时间设置为2小时。用户在权限校验时，直接从Redis取，取不到再查数据库，同时回填缓存。
数据字典缓存也是同样的思路，例如请假类型的字典、公告类型的字典，这些数据稳定且高频使用，缓存在Redis里能极大减少对数据库的重复查询。缓存key失效策略上，我选择的是超时失效，没有做主动更新，因为字典变更频率真的很低，2小时后再查一次数据库刷新缓存，是可接受的行为。
3.4 大文件上传的实现与处理
企业OA系统里，文件上传是很常见的操作。小文件后端直接用MultipartFile接收，很容易实现。但一旦涉及大文件，比如培训视频、项目资料压缩包，默认配置就不够用了，会出现连接超时、内存溢出、文件大小超限等问题。
我的方案是分片上传。前端把大文件切成多个分片，比如每片5MB，按顺序调用上传接口。后端每收到一个分片，就写到临时目录里，记录到上传分片表。所有分片上传完成后，前端调用一个合并接口，后端把所有分片按顺序合并成一个完整的文件，然后删除分片记录。
这个方案有几个好处：一是任何一片上传失败只需要重传那一片，不需要整个重来，用户体验好很多；二是每块分片都不大，不会造成内存压力；三是合并过程在后端完成，可以实时校验文件完整性和计算MD5值，防止传输过程中文件被损坏。
另外一个关键配置是Spring Boot的文件上传参数。如果忘了调大spring.servlet.multipart.max-file-size和spring.servlet.multipart.max-request-size，就算代码逻辑没问题，前端传一个30MB的文件也会直接报错。我在配置里将这两个值都调整到了100MB，给分片上传留足余量。
3.5 自定义Banner与项目规范
热词里出现了一个有趣的词：Spring Boot banner生成器。这个点虽然小，但确实是很多Spring Boot开发者的日常乐趣。默认启动时控制台打印的Spring Boot标志，是可以替换成自己的文字的，或者用ASCII艺术字。
我建议在项目启动的logback配置里，把日志输出格式也统一规范一下，这样排查问题的时候看日志会舒服很多。项目规范的另一个重点，是Controller、Service、Mapper的包结构规范，以及命名规范。我在项目里约定Controller层以Controller结尾，Service接口以Service结尾、实现类加Impl后缀，方法名要能直接表达业务语义，例如submitLeaveRequest、approveApplication，避免出现doIt、handle这种看了不知道在干什么的方法名。
代码规范还有个容易踩的坑，就是Lombok在高版本JDK下的兼容性问题。你可能会看到报错提示“you aren't using a compiler supported by lombok, so lombok will not work”。这是因为JDK版本太新，而项目里的Lombok版本太老。解决方法是升级Lombok到1.18.30以上的版本，或者把JDK版本降回项目依赖的版本。我在开发时踩过的具体细节后面会专门展开。
4. 项目部署、运行环境与测试实战
4.1 环境准备与关键配置说明
这个项目的标准运行环境是JDK 1.8或JDK 11，Maven 3.6以上，MySQL 8.0，Redis 5.0以上。如果你用JDK 17跑，一定要确保Spring Boot版本至少是2.7以上，同时Lombok和Maven编译插件版本都同步升级，否则很容易出现各种版本不兼容的诡异问题。
这里有一个高频报错必须先讲，就是编译时的“源发行版 17 需要目标发行版 17”错误。这个错误的本质是Maven编译时使用的JDK版本和项目pom.xml里配置的Java版本不一致。比如你的IDE用JDK 17在跑，但pom里配置的是1.8，就会报“源发行版 1.8 需要目标发行版 1.8”，反过来说如果你的IDE默认用JDK 17、pom里也写了17，idea里Project Structure设置成8，就会报你想把源码编译成8但当前JDK只支持17的情况。解决办法是统一三处：pom.xml里的maven.compiler.source和maven.compiler.target、IDE的Project SDK、Maven的Runner JRE。这三处必须指向同一个JDK版本。
application.yml是Spring Boot项目的核心配置文件，我简单列一下几个关键的配置项：数据源的URL、用户名、密码；Redis的连接信息；MyBatis Plus的逻辑删除和分页拦截器；文件上传大小的限制。密码我强烈建议用环境变量注入，不要直接写在application.yml里提交到代码仓库，避免数据库密码泄露到Git历史里，这个坏习惯在真实企业项目里是很严重的安全隐患。
4.2 前后端分离部署与跨域问题
这个项目是前后端分离架构，前端Vue项目开发时通过代理把接口请求转发到后端，生产环境则把前端打包成静态文件放在Nginx里。这里涉及到两个关键点：跨域配置和API转发配置。
开发环境下，前端访问后端接口必然产生跨域，我在后端加了一个CorsFilter，允许指定来源的跨域请求，同时允许携带凭证。跨域配置要精确到允许的来源域名，不能为了省事直接配置成*，否则在需要携带Cookie或认证信息时会失败，并且安全性也会降低。
生产环境下，Nginx的配置是：前端静态文件由Nginx直接serve，接口请求通过location /api/的反向代理转发到后端的Java应用。这样做的好处是前端和后端共享同一个域名，浏览器里没有任何跨域问题，Cookie和登录态也更容易管理。
我在写Nginx配置时专门给前端路由的history模式加了一行try_files配置，确保路由刷新时不会404。很多前后端分离项目上线后出现“点击进入二级页面正常，一刷新就404”的问题，就是少了这一行配置。
4.3 单元测试与接口联调实践
很多人写项目最不爱做的事就是写单元测试，但等系统跑起来用户一多、数据一复杂，你就知道测试的价值了。我在写这个OA系统的核心模块时，为Service层写了完整的单元测试，重点覆盖有复杂业务逻辑的接口，例如审批流程的推进、考勤天数的计算、角色权限的变更。
测试策略上，我采用了H2内存数据库，在测试环境下自动建表、自动初始化数据，这样测试用例不需要依赖开发库，也避免了污染真实数据。针对每个测试用例，用JUnit 5的@BeforeEach初始化测试数据，Service方法执行完后用断言校验结果。例如请假审批的测试，我会构造一个请假申请单，模拟部门经理审批通过，断言流程状态变更为“人事复核”，审批记录表里新增了一条审批记录，这就是一个典型的业务闭环测试。
Mock数据方面，对于需要调用外部接口的逻辑，比如地图定位打卡、消息通知推送，我用Mockito做了mock，只验证业务逻辑本身，不依赖外部服务的可用性。
4.4 Docker部署与资源限制问题
项目收尾后部署上线，我选择了Docker方式。Dockerfile很简单，基础镜像用eclipse-temurin:8-jre，把打包好的jar文件复制到镜像里，暴露8080端口，启动命令是java -jar。这里有一个热词提到了“springboot jdk1.8打包到docker desktop”，说穿了就是注意一下基础镜像的选择和Maven构建时的JDK版本一致性。
Docker部署有一个容易忽略的问题，就是容器内存限制。Spring Boot应用默认的堆内存设置是物理内存的四分之一，如果在容器里不显式设置堆内存参数，很容易出现OOM。我在Docker的启动命令里加了JVM参数：-Xms512m -Xmx1024m，限制堆内存上限，同时加了-XX:+UseG1GC使用G1垃圾回收器，减少GC暂停时间。如果你是直接宿主机部署，同样要记得在处理脚本里加上这些JVM参数，避免出现“java: OutOfMemoryError: insufficient memory”这类问题。
部署数据库和Redis，我同样用Docker Compose编排了MySQL和Redis容器，设置好数据卷映射，这样即使容器销毁，数据也不会丢失。项目配置文件和jar包分离，环境变量从docker-compose.yml里注入，部署到新环境时只需要改环境变量，不用重新构建镜像。
5. 常见问题与详细排查方案
做项目最耗时间的往往不是写代码，而是排查问题。我把这个OA系统开发过程中遇到过的典型问题整理出来，按出现频率排序，分享给大家做排查参考。
| 错误现象 | 根本原因 | 解决方案 |
|---|---|---|
| 编译报错：源发行版17需要目标发行版17 | Maven编译器插件版本与JDK版本不匹配 | 统一pom.xml、IDE Project SDK、Maven Runner三处的JDK版本 |
| Lombok报错：not working | Lombok版本和当前JDK不兼容 | 升级Lombok到1.18.30+，或将JDK降回项目依赖的版本 |
| java: OutOfMemoryError: insufficient memory | JVM堆内存设置不足，元空间溢出 | 启动命令增加-Xmx参数，限制堆内存；排查死循环或大对象持有 |
| Spring Boot版本太高导致整合MyBatis Plus失败 | 依赖版本之间存在冲突 | 锁定Spring Boot 2.7.x配合MP3.5.x，或升级MP到适配的版本 |
| 文件上传报MaxUploadSizeExceededException | 上传大小限制配置未调整 | 配置spring.servlet.multipart.max-file-size和max-request-size |
| 前端接口请求跨域 | 前后端分离跨域配置缺失 | 配置CorsFilter，允许指定来源的跨域请求 |
| Vue刷新404 | 前端history路由模式未配置 | Nginx增加try_files配置 |
| 分页查询查全表 | MP分页插件数据库类型未设置或插件未装配 | 配置PaginationInnerInterceptor并设置DbType.MYSQL |
| 时间字段为null | 未配置自动填充或数据库默认值设置不对 | 启用MetaObjectHandler自动填充，表字段设置默认值 |
| Filter中注入的Service为null | Filter生命周期由容器管理，不在Spring容器中 | 通过SpringBeanAutowiringSupport或ApplicationContext获取Bean |
第一个问题，“源发行版17需要目标发行版17”，我前面讲过一次，这里再补充一个排查思路。这个报错还有一个常见的变体：IDEA里能正常运行，但Maven命令行打包就报错。原因是IDEA默认使用的JDK版本和Maven运行时使用的JDK版本不一致。在IDEA的Settings里搜Maven，找到Runner设置，有一个JRE选项，把它也指到和项目同一个JDK。这一处不改，代码在开发环境跑得好好的，一把包就报版本错误，很耽误事。
第二个问题，Lombok的坑。现在新项目如果直接用JDK 17或者更新版本，首先要检查Lombok版本。老版本的Lombok内部通过编译器API去识别注解，新JDK改了内部机制以后，老版本就失效了。升级到Lombok 1.18.30后基本可以解决，如果还不行，就检查Maven编译插件的版本，把maven-compiler-plugin升级到3.11.0以上，基本能全覆盖。
第三个问题，OutOfMemoryError。这个我在Docker部署时遇到过几次。排查思路分三步：先看启动参数的-Xmx设置是不是太小；然后用jmap或VisualVM查看堆内存的占用情况，看是堆内存不够还是元空间不够；最后看业务代码里有没有可能存在大批量加载数据到内存的逻辑。比如导出报表时直接用list查询把所有记录加载到内存，几万条数据在内存里构建对象，非常容易OOM。正确做法是使用流式查询或分页查询，每次只处理一小部分。
第四个问题，Spring Boot版本太高引起的整合失败。这属于比较典型的依赖冲突问题。Spring Boot 3.0之后整体迁移到了Jakarta EE，javax包名全部变成了jakarta，MyBatis Plus的旧版本如果基于javax编译，在Spring Boot 3下直接就会启动失败。如果你对新版本不熟，建议不要急着上Boot 3，老老实实用Spring Boot 2.7.x，兼容性最好。后期的项目如果要升级Batch 3，再系统性测试一遍所有依赖。
6. 系统扩展方向与面试高频考点
整个项目做完之后，我最大的感受是OA系统是一个极其适合做扩展的项目底座。核心流程跑通之后，你可以在这个框架上继续叠加很多实用模块。
第一个扩展方向是接入企业微信或钉钉。企业微信和钉钉都提供了开放API，可以实现免登、消息推送、审批消息触达等功能。这样员工不用专门打开OA系统，在钉钉里就能收到审批通知，点击链接直接跳转到H5页面处理审批，体验感和使用率都会有明显提升。
第二个扩展方向是数据可视化大屏。把考勤数据、审批数据、公告阅读数据、人员流动数据汇聚起来，做一块领导驾驶舱大屏，用图表展示企业运转的状态。技术上可以用ECharts或Vue-admin-webapp的集成方案，数据接口从现有业务数据中聚合统计即可。这块做好了对管理层的决策辅助价值非常高，也最能体现一个开发者的业务理解能力。
第三个扩展方向是引入消息队列。当审批流程推进、公告发布、考勤异常时，系统需要发送站内信、邮件、短信通知。如果通知逻辑全部同步走，会影响主流程的响应速度。用Spring Boot整合ActiveMQ或RabbitMQ，把通知发送丢到消息队列里异步处理，主流程只关心业务状态变更，通知是否送达、是否失败重试交给队列去管，这也是热词里提到的“Spring Boot整合ActiveMQ”的现实场景。
现在回归到Java面试这个事上。如果你打算带着这个项目去面试，有几个高频考点一定要准备扎实。第一，Spring Boot自动装配原理，这个几乎是必考题，你要能讲清楚@SpringBootApplication、@EnableAutoConfiguration、spring.factories/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports这些机制是怎么串联起来的。第二，Spring Security的过滤器链流程，JWT的认证和授权过程，为什么选无状态认证。第三，MyBatis Plus分页插件的实现原理，逻辑删除是怎么实现的。第四，Spring Boot的starter机制，它是怎么把依赖和自动配置绑定在一起的。第五，面向对象设计在这套系统中怎么体现的，比如审批策略模式、文件存储的接口抽象。
在Java基础上，面试官大概率还会追问你一些八股文式的基础题，比如冒泡排序的时间复杂度、Lambda表达式的原理和应用场景、Java环境变量配置、运算符优先级这些。这些都是Java开发的基本功，项目经验是敲门砖，基础扎实才能走得更远。我把这些常见的Java面试题点和项目里的对应实践结合起来去准备，面试的时候就能做到既懂理论、又有实践例证，比单纯背八股文生动有力得多。
这套OA管理系统目前还在持续迭代，我也在工作中不断根据使用反馈来优化流程体验。如果你也在做类似的项目，有几个建议可以听进去。第一，权限模型一定不要为了省事而简化，后续维护的成本会让你后悔。第二，流程引擎最初选择轻量实现，等到真实需求明确之后再考虑是否升级。第三，日志一定从第一天就做全，等出了问题再回头补日志，你根本不知道当时发生了什么。第四，代码规范是团队协作的地基，比功能实现更值得投入时间。
最后再分享一个小技巧：因为这个项目的模块足够多、业务链路足够完整，找工作面试时把它作为主推项目来介绍，比自己造一个项目要扎实可信得多。把业务链路捋清楚、把技术选型背后的取舍想明白、把部署运维的细节讲透，你收获的不只是一个能跑的项目，更是面试时表达自己真正理解技术栈的底气。
