1. 选题背后的真实考量：为什么办公自动化系统依然是毕业设计的"安全牌"
每年到了毕业设计选题季，总有一批人纠结：是跟风做一个短视频推荐算法、搞一个前后端分离的电商项目，还是选一个看起来不那么"性感"但实用性很强的管理系统？
我当时的答案很直接：做企业办公自动化系统（OA系统）。原因有三条，现在回头看依然成立。
第一，这类系统是典型的"业务逻辑重、算法含量低、展示效果直观"的项目。毕业设计考察的重点从来不是你能不能搞出一个惊天动地的模型，而是你对业务的理解、对软件工程流程的把握、对主流技术栈的熟练度。OA系统恰好把这三样都占了。
第二，Java技术栈在企业级应用中的生态太成熟了。Spring Boot、MyBatis Plus、MySQL这套组合，在真实企业的中小型内部系统里依旧是主力。做了这个课题，答辩时被问"你为什么用这个技术"时，你能拿出真实世界的理由，而不是说"因为教程里这么写"。
第三，企业办公自动化系统的业务场景足够具体。审批、考勤、通知公告、会议管理、员工通讯录——这些场景每个人都见过、用过，需求不需要凭空想象，答辩时的需求分析部分特别好讲。反观某些课题，做完之后连"这个项目到底解决什么问题"都要现场编。
这个课题的另一个隐形优势是资料密度大。网上能找到的课程设计、毕业设计源码很多，哪怕你最终要自己动手写，参考资料的丰富程度也远高于冷门课题。我当时就是先在GitHub和CSDN上收集了五六个同类项目的源码和文档做对照，把模块设计和表结构梳理清楚，再动手自研，效率比从零开始高出一大截。
不过这里要先泼一盆冷水：不要抱着"下载源码改个名字就能交"的心态做这个课题。老师对OA系统的熟悉程度远超你的想象，一问你表结构、一问流程状态怎么流转，照本宣科还是真懂立马见分晓。源码可以做参考和起点，但核心代码必须自己吃透、能复现、能优化。
2. 系统模块怎么拆：不是功能越多越好，而是闭环越顺越好
2.1 核心业务模块的边界划分
企业办公自动化系统的功能需求，看起来是无底洞：人事、财务、行政、项目、客户，什么都能往里塞。但毕业设计讲究的是"合理范围"内形成闭环，我最后敲定的模块边界是六个：
- 系统管理：用户管理、角色管理、菜单权限、操作日志。这是所有系统的底座，没得商量必须有。
- 审批中心：请假申请、报销申请、用印申请。三种申请共用一套审批流，这是整个系统的核心亮点，也是最值得在论文里详细展开的部分。
- 考勤管理：打卡记录、考勤统计。这个模块的实时性要求让项目"活"了起来。
- 通知公告：管理员发布公告，员工按部门或全员接收。功能极简，但前端展示效果好，答辩演示时一屏就能说清楚。
- 会议管理：会议室预定、会议邀请、冲突检测。这个模块容易做出差异化，我加了时间冲突校验。
- 个人中心：待办事项、已办事项、个人资料修改。
确定边界后，我做的第一件事不是写代码，而是画用例图和业务流程图。很多同学跳过这一步直接建表，结果写到后半程发现业务关系理不清，来回改表结构。用例图画完的那天，我心里就有底了——每个角色的动作、与系统的交互边界都清晰了，后面建表和写接口的速度反而比"边写边想"快了不止一倍。
2.2 数据库表设计的几个关键取舍
表结构是整个系统的地基，地基歪了，后面写多少代码都是在填坑。我设计表的时候有几个比较深的体会：
一是用户表、角色表、权限表的关系模型尽早确定。OA系统里最常见的权限模型是RBAC（基于角色的访问控制），也就是五张表：用户表、角色表、权限表、用户角色关联表、角色权限关联表。这里有个容易走偏的地方：很多人一开始给每张表塞十几个字段，"可能以后用得上"的心态作祟。我的原则是能不加的字段一律不加，字段冗余只出现在关联查询频繁、且数据基本不变的地方。
二是审批相关的表一定要预留流程痕迹。OA系统的审批，做的不是"审批结果"，而是"审批过程"。我设计了审批记录表，每一条审批动作都记录操作人、操作时间、审批意见、处理结果。这个设计让系统能回答"谁在什么时候批了还是拒了"这类溯源问题，也是答辩时老师最可能追问的地方。
三是状态字段用整型不用字符串。请假单的状态（待提交、审批中、已通过、已驳回）用0、1、2、3存，评论部分再用文字解释。字符串做状态值看着直观，但对于程序判断和索引很不友好，这是我在开发过程中反复改出来的教训。
2.3 用MyBatis Plus根据Java实体类生成建表SQL的实际操作
开发过程中我用到过一个非常省事的操作：用MyBatis Plus的代码生成器和自动建表能力，直接从Java实体类生成数据库表。
常规做法是手写SQL建表，但当你定义的实体类字段多到二三十个时，手写建表语句的效率就明显跟不上了。MyBatis Plus提供了一种思路：先在Java类上定义好字段和注解，再用工具生成对应的建表语句。
具体做法不复杂。实体类里写清楚字段类型和约束，比如：
@Data @TableName("oa_leave_apply") public class LeaveApply { @TableId(type = IdType.AUTO) private Long id; @TableField("user_id") private Long userId; @TableField("leave_type") private Integer leaveType; @TableField("start_time") private LocalDateTime startTime; @TableField("end_time") private LocalDateTime endTime; @TableField("reason") private String reason; @TableField("status") private Integer status; @TableField("create_time") private LocalDateTime createTime; }然后配置一个自动建表或代码生成的插件，或者直接用MyBatis Plus Generator把实体类、Mapper、Service、Controller一层全部反向生成出来。倒不是说依赖这个节省了多少时间，而是它保证了实体类字段和表结构的一致性，杜绝了手写SQL时字段名拼写不一致导致的跑批排查。
这里要提醒一句：代码生成器生成的CRUD只是样板代码，真正的业务逻辑（比如审批流的流转判断、考勤的迟到早退计算）必须自己手写。生成器是帮你起跑，不是帮你跑完全程。
3. 后端开发中的"必踩三坑"：登录、权限、审批流
3.1 登录认证的实现思路
登录认证是OA系统躲不开的第一道坎。我最初打算用Spring Security，配置了两天，加了一堆过滤器、配置类、UserDetailsService实现，结果和JWT整合的时候各种报错，搞到半夜心态都快崩了。
后来换了一个轻量级的思路：Sa-Token。它的核心API简单直观，登录、鉴权、踢人下线的功能都有。用它做完整个认证流程只花了一个晚上。倒不是说Spring Security不好，而是对于毕业设计这个量级的项目，Spring Security的重量级抽象反而成了负担。
最终登录验证逻辑是这样的：用户提交账号密码，后端用BCrypt加密算法校验密码原文，校验通过后生成一个token返回给前端。前端在请求头里带上这个token，后端通过拦截器统一做凭证校验，解析当前用户是谁。整个链路里最重要的是三件事：
- 密码绝对不能明文存数据库，用BCrypt加盐存储；
- token要设置过期时间，OA系统一般建议4到8小时，太短影响办公体验，太长有安全风险；
- 拦截器要放行登录接口和静态资源，不然前端还没拿到token就被后端拦了。
我在这个环节写过一个典型的Bug：拦截器把/api/login之外的接口都拦截了，结果前端拿着正确的账号密码登录，却始终报"401未登录"。排查了很久发现是拦截器的排除路径没有生效，因为我的路径匹配规则写的是/api/**，但登录接口实际路径是/api/login，这个排除配置本身没问题，问题出在拦截器注册顺序上，后来调整了配置类里的过滤器顺序就正常了。
3.2 RBAC权限校验的落地方式
权限校验这块，很多教程喜欢讲"按钮级权限""接口级权限"的花活，但毕业设计能把"角色区分"这件事做实就已经很扎实。
我的做法是后端接口统一做角色校验，前端菜单按权限动态渲染。后端有个@SaCheckPermission("system:user:add")之类的注解，标注在新增用户的接口上；前端则根据当前用户的权限数组决定菜单显示/隐藏。这样即使有人绕过前端直接调用接口，后端依然会拒绝。
关于权限设计，我想多说一点：权限码的设计要有规律可循。我采用模块:功能:操作的三段式命名，比如oa:leave:apply、oa:leave:approve、system:user:resetPwd。这样后端代码里对着权限码就能知道控制的是什么，数据库中维护权限数据时也不容易乱。
3.3 审批流的状态机抽象
审批流是整个系统的灵魂，也是最容易写成一团乱麻的地方。
我的做法是引入状态机思维，不引入Flowable这类重量级工作流引擎。三种申请（请假、报销、用印）抽象成一个通用的流程模板：每个申请单有一个当前状态，每次审批动作触发一个状态迁移。
状态定义如下：
| 状态值 | 含义 | 可执行动作 |
|---|---|---|
| 0 | 草稿 | 提交 |
| 1 | 审批中（待上级审批） | 通过 / 驳回 |
| 2 | 已通过 | 归档 |
| 3 | 已驳回 | 修改后重新提交 |
审批动作统一在ApprovalController里处理，不同申请类型的差异通过策略模式封装出去。比如请假要判断假期余额够不够，报销要判断发票金额是否匹配，这些差异逻辑各自写在对应的策略类里，审批主流程不关心具体业务规则，只关心"当前状态能不能执行这个动作"。
这个设计的价值在于：答辩时你能理直气壮地说"我用状态机规范了审批流程，用策略模式隔离了业务差异"，这是明确的软件工程加分点。
我在这个地方踩过的坑是：状态流转出现死循环。最开始用if-else嵌套处理流转逻辑，三个审批层级下来代码已经面目全非，排错时看着一堆if头都是大的。后来重构为状态迁移表（一个Map，key是"当前状态+操作动作"，value是"目标状态"），整个流转逻辑变成查表操作，不到一百行代码解决的问题，之前用if-else写了三百多行还漏了边界。
4. 接口设计与前端联调：把"能跑"变成"好用"的关键环节
4.1 统一响应结构的坑与价值
后端接口返回结构不统一，是前后端联调时最折磨人的事。我第一次写接口时，有的接口返回{code: 0, data: ...}，有的返回{success: true, data: ...}，前端同事（其实就是另一个熬夜写代码的我）被迫在axios拦截器里写一堆兼容逻辑。
后来我们统一封装了Result<T>：
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> ok(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> fail(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }这样做的直接好处是：前端只用判断code === 200，其他都算失败，统一弹异常提示。项目回归测试时，接口调用的代码量降低了大概三成。
4.2 分页查询的两种官方姿势
OA系统的列表页几乎全部要分页：申请列表、用户列表、日志列表。MyBatis Plus内置分页插件，用法很简单，但有两个细节容易踩：
- 分页插件必须配置
PaginationInnerInterceptor到MyBatis Plus的拦截器链里，不配置的话分页SQL不会自动加上LIMIT，查出来就是全量数据。 - 前端传页码时，约定
pageNum从1开始还是从0开始，一定要和后端注解对清楚。我见过太多因为PageHelper.startPage(pageNum, pageSize)和前端传的值差1导致列表少一行的案例。
分页查询在实际开发里还有一个性能点：不要select所有字段。OA系统的申请单列表只需要列表展示那几列，详情页才需要全部字段。全部查出来在数据量小的时候看不出来，但答辩演示时如果造了几千条测试数据，页面的响应速度差异是肉眼可见的。
4.3 联调阶段我反复改动最多的三个接口
回顾整个开发过程，联调阶段的返工主要集中在这三个点：
第一个是审批状态变更后列表状态没同步刷新。原因是前端在审批操作后没有重新请求列表数据，还在用本地缓存的状态去渲染。解决办法很土但很有效：审批接口调用成功后，强制刷新当前列表页。
第二个是时间格式的传输问题。后端返回LocalDateTime默认序列化成2024-05-20T10:30:00，这种带T的格式在浏览器上显示非常丑。后来通过配置全局Jackson序列化，把日期格式统一成yyyy-MM-dd HH:mm:ss，一次性解决了所有页面的时间显示问题。这个操作在答辩演示时特别加分，因为大多数同学的系统里时间格式都是乱的，即使功能正常，观感也差了。
第三个是文件上传的路径问题。OA系统往往涉及附件上传（比如报销单电子发票、用印申请扫描件），文件存到服务器本地目录后，前端访问用的是相对路径，本地开发、部署到服务器两种场景下路径对不上。最后用配置类统一管理上传根路径，再通过一个/files/**的静态资源映射暴露出去，才算真正解决。这个点不只是联调坑，也是部署阶段的坑，提前用配置管理能省很多事。
5. 部署、打包和答辩演示的实操细节
5.1 Maven打包的常见翻车点
开发环境一切正常，一打包出问题，这是最常见的情况。项目用Maven打包时最容易翻车的几个点是：
- 本地JDK版本和打包环境不一致。开发用JDK 17，服务器用JDK 8，而Maven编译配置里没有指定
maven.compiler.source/target，打出来的包可能在刷新环境时报"UnsupportedClassVersionError"。我建议在pom.xml里明确规定Java版本属性。 - 测试代码拦截打包。默认
mvn package会执行测试，如果测试类里有连接数据库的用例，构建时就会因为连不上库而失败。毕业设计阶段直接在pom.xml里跳过测试，稳定优先。 - 前端静态资源的合并。如果项目是前后端不分离的结构，前端资源放在
src/main/resources/static下，打包时会自动打进jar包。我就遇到过页面样式文件被压缩后路径错乱的问题，排查到最后发现是自定义了一个base标签，把静态资源根路径指错了。
5.2 答辩演示前必须准备的几样东西
答辩演示是最容易被低估的环节。代码跑通了，功能都正常，不代表答辩就稳了。我总结了几条非常实在的准备事项：
第一，准备一份干净的演示数据脚本。演示数据要覆盖各种状态：审批中的单子、已驳回的单子、待我审批的单子，每种至少一条。答辩现场不可能给你时间去填数据，脚本一键初始化，直接点到最有说服力的页面。
第二，把流程完整走一遍，别跳着点。我见过一个同学演示考勤模块时，直接跳到统计页面说"这是考勤统计"，却忽略了打卡动作本身的操作演示。正确的演示逻辑应该是：创建一个用户、用这个用户打卡、再切换管理员看统计结果，形成一个完整的操作链路。
第三，准备好一张"A0图表"。所有模块的架构图、E-R图、流程图，打印成一张大图摆在那里。这不是形式主义，答辩时老师提问，你指着图讲比对着屏幕讲要清楚十倍。
5.3 部署环境配置的一次完整复盘
我项目的最终部署环境是腾讯云的一台轻量服务器，配置是2核4G，系统Ubuntu 22.04，装了MySQL 8.0和OpenJDK 8。部署过程本身不复杂，但有几个点值得单独说：
数据库这一侧，需要注意编码问题。生产库初始化时没指定utf8mb4，导致中文插入后乱码。排查方法很简单，不管先确认数据库、连接串、表三层的字符集是否一致。我最后统一设置了characterEncoding=utf8mb4，问题彻底消失。
项目以jar包运行后，记得设置JVM参数。java -Xms256m -Xmx512m -jar oa-system.jar，控制一下内存占用，4G内存的服务器跑OA系统和MySQL完全够用。
还有一处当初折腾了很久的坑：端口被防火墙拦截。项目默认端口8080，放行后访问仍然超时，最后发现是云服务器的安全组没配置入站规则。这个坑属于典型的"代码没问题，环境有问题"，如果遇到类似情况，方向要优先往环境排查。
6. 写在最后的一些实操心得
如果让我重新做一次这个课题，我会在三个地方投入更多时间：第一，数据库设计阶段再多花一天把所有关联关系过一遍；第二，审批流的策略模式一开始就设计好，而不是写到一半再重构；第三，多花时间在演示脚本和页面细节上——这些看起来不起眼的工作，最终带来的答辩收益远超多写两个功能模块。
另外，给各位一个非常诚恳的建议：拿到任何参考源码，第一件事不是看功能，而是看它的数据库脚本和实体类关系。了解了表怎么设计的，就了解了这个项目的地基结构，剩下的无非是在上面盖楼。把这一点吃透了，哪怕你完全不抄任何代码，也能凭自己的理解重写出一套更好的系统。
最后再分享一个关于"写论文"的小技巧。OA系统的论文结构里，最难写的部分是"系统设计"这一章，很多同学会写成一堆功能列表的罗列。我当时换了一个思路，每个模块从"业务场景→数据模型→接口设计→界面展示"四个维度展开，配上自己画的E-R图和流程图，论文看上去真的像一篇"系统设计"的文章，而不是功能说明书。这个方法希望也能帮到你。
