1. 项目拆解：这套系统到底在解决什么问题
先亮个底，这套基于 Spring Boot 的智能办公室管理系统，说白了就是把公司里那些靠人盯、靠纸记、靠口头传的琐事，全部搬到线上自动流转。什么会议室预订、访客登记、工位分配、设备报修、公告通知、考勤统计，这些行政场景里最占时间又最容易扯皮的环节，正是这套系统要收拾的“重灾区”。
我最早接触这类项目时也犯过嘀咕：办公室管理有什么好“智能”的？不就是个 OA 换皮吗？真做下去才发现，难点根本不在增删改查，而在“状态流转”和“权限边界”——一个会议室从申请到审批到使用再到释放，中间涉及多少人、多少种角色、多少种异常情况，这些东西才是拉开普通毕设和真正能落地系统之间差距的地方。
这套系统适合谁来参考？如果你是正在做毕业设计、想搞一套拿得出手的 Spring Boot 项目的在校生，或者刚入职准备接手公司内部管理系统开发的新人，这个选题都非常合适。它不像电商、秒杀那些项目一样重并发、重缓存，而是把重心放在业务建模、权限设计、流程状态机上，这些恰恰是面试时最能讲清楚、最能体现“业务理解能力”的部分。
从技术栈上看，Spring Boot 负责后端接口和业务逻辑，前端可以搭配 Vue 或者直接用 Thymeleaf 模板引擎，数据库用 MySQL，权限框架用 Spring Security 或者 Shiro。这套组合在国内中小型管理系统里非常主流，学会了以后换任何业务场景都套得上。后面我会把项目的核心架构、模块设计、关键实现和踩坑记录挨个拆开讲，尽量让你照着就能复现出来。 ## 1. 项目拆解：这套系统到底在解决什么问题
先亮个底，这套基于 Spring Boot 的智能办公室管理系统，说白了就是把公司里那些靠人盯、靠纸记、靠口头传的琐事，全部搬到线上自动流转。会议室预订、访客登记、工位分配、设备报修、公告通知、考勤统计——这些行政场景里最占时间又最容易扯皮的环节，正是这套系统要收拾的“重灾区”。
我最早接触这类项目时也犯过嘀咕：办公室管理有什么好“智能”的？不就是个 OA 换皮吗？真做下去才发现，难点根本不在增删改查，而在“状态流转”和“权限边界”——一个会议室从申请到审批到使用再到释放，中间涉及多少人、多少种角色、多少种异常情况，这些东西才是拉开普通毕设和真正能落地系统之间差距的地方。
这套系统适合谁来参考？如果你是正在做毕业设计、想搞一套拿得出手的 Spring Boot 项目的在校生，或者刚入职准备接手公司内部管理系统开发的新人，这个选题都非常合适。它不像电商、秒杀那些项目一样重并发、重缓存，而是把重心放在业务建模、权限设计、流程状态机上，这些恰恰是面试时最能讲清楚、最能体现“业务理解能力”的部分。
从技术栈上看，Spring Boot 负责后端接口和业务逻辑，前端可以搭配 Vue 或者直接用 Thymeleaf 模板引擎，数据库用 MySQL，权限框架用 Spring Security 或者 Shiro。这套组合在国内中小型管理系统里非常主流，学会了以后换任何业务场景都套得上。后面我会把项目的核心架构、模块设计、关键实现和踩坑记录挨个拆开讲，尽量让你照着就能复现出来。
2. 整体架构与设计思路
2.1 为什么选 Spring Boot 而不是 SSH 或 Spring Cloud
这个项目叫“基于 Spring Boot”，那就先从框架选型说起。很多人写毕设或者做内部小系统，纠结到底用 Spring Boot 还是传统的 SSM（Spring + SpringMVC + MyBatis）。我的建议非常直接：只要不是公司强制要求老技术栈，一律 Spring Boot。
原因不复杂。第一，Spring Boot 内置了 Tomcat，不用再单独部署 war 包，一个 java -jar 就起来了，部署成本低到可以忽略。第二，自动配置机制省掉了大量 XML 配置，你写一个数据源、配一个 MyBatis 扫描路径就能跑通全链路。第三，也是最现实的一点，现在企业里新项目基本都切 Spring Boot 了，你拿这个做完毕业设计，简历上写的是“基于 Spring Boot 的XX系统”，面试官看着顺眼，不用先解释一遍 SSH 那套老古董。
那为什么不用 Spring Cloud？也很简单，这是一套单机可运行的管理系统，没有分布式需求。Spring Cloud 那套注册中心、配置中心、网关、负载均衡，加进来除了让你的电脑风扇转得更快一点，没有任何实际收益。架构选型这件事，永远遵循“够用就好”的原则，不是你会的越多就越该往项目里塞。
2.2 前后端分离还是服务端渲染
这个项目我用的是前后端分离的方案：后端纯接口，返回 JSON，前端用 Vue + Element UI 搭管理后台。这么做有几个实际好处。
第一，调试方便。后端接口用 Postman 或者 Apifox 一测就知道逻辑对不对，不用等前端页面渲染完才能看到效果。第二，职责清晰。我在开发过程中把接口文档先列出来，前端和后端各干各的，互不阻塞。第三，答辩或面试时有得聊。你可以在项目介绍里说“前端用 Vue 的响应式数据绑定，后端用 RESTful API 设计”，这些都是加分项。
但如果你的前端基础比较薄弱，或者时间特别紧，我会建议直接用 Thymeleaf 模板引擎。它不是不能做，而是每改一个页面就要重新编译启动，调试效率低一些。不过好处是不用管跨域问题、不用配 Nginx、不用处理 Token 传递，所有的页面跳转都由后端控制，逻辑更直白。两种方案没有绝对好坏，核心是看你的时间预算和前端水平。
2.3 数据库设计的核心：权限模型与业务表解耦
这部分是整个系统的地基，我单独拿出来说。智能办公室管理系统里最核心的不是会议、不是工位，而是“谁能用什么功能、谁能看什么数据”这个问题。我这里用的是经典的 RBAC 模型——用户表、角色表、权限表，再加上用户-角色关联表和角色-权限关联表。
为什么不直接把权限字段写在用户表里？因为那样做，每加一种权限你都要改表结构，加一个用户要配一大堆字段，后期维护完全是噩梦。RBAC 模型的本质是“用户不直接和权限挂钩，用户属于角色，角色拥有权限”。这就像一个公司里，你不是直接领任务，而是你先有了某个岗位，岗位规定了你要干活的内容。
业务表的设计上，我遵循的原则是“高内聚、低耦合”。会议室表只管会议室的基础信息，预订记录单独一张表，审批流程单独一张表，它们之间通过外键或者逻辑外键关联。千万不要把预订状态直接塞进会议室表里——否则当你要统计“哪些会议室今天被订了多少次”的时候，SQL 写得你怀疑人生。
3. 核心模块设计与实操要点
3.1 用户认证与权限控制：Spring Security 的正确用法
用户登录这块，我强烈建议直接用 Spring Security，别自己写拦截器或者过滤器去做鉴权。不是说自己写不行，而是 Spring Security 的过滤器链机制、会话管理、密码加密这些功能已经很成熟了，你花时间重复造轮子，不如把精力放在业务逻辑上。
具体实现上，我先自定义了一个 UserDetailsService，从数据库里查用户信息和角色信息，然后封装成 UserDetails 返回。密码加密用的是 BCryptPasswordEncoder，这个加密算法的好处是每次加密同一个密码得到的结果都不一样，因为里面带了随机盐，就算数据库泄露了，攻击者也没法直接反推密码。
接口鉴权我用了注解方式，在 Controller 的方法上打 @PreAuthorize，比如会议室管理接口要求 ADMIN 角色才能访问，普通员工只能查看会议室列表。这种方式比在配置类里写一大串 antMatchers 要直观得多，代码和数据权限的对应关系一眼就能看清。
有几点要特别提醒。第一，Spring Security 的过滤链顺序千万不能乱，自定义过滤器要放在 UsernamePasswordAuthenticationFilter 之前或者之后，位置错了会导致请求还没认证就进了业务代码。第二，前后端分离项目里，默认的登录页跳转逻辑必须禁用，否则请求未认证时会返回 302 而不是 401，前端处理起来非常别扭。第三，密码加密器在项目启动时就要配置好，千万别用 NoOpPasswordEncoder，那是明文比对，属于直接裸奔。
3.2 会议室预订模块：并发冲突与状态校验
会议室预订是这个系统里业务逻辑最复杂、最容易出 bug 的模块，我前后改了三版才算稳定。核心难点在于“同一时间段不能重复预订”这个约束。
我第一次实现的时候，就是用户提交预订，后端查一下该会议室在该时间段有没有记录，没有就插入。这个逻辑单线程跑没问题，但两个人同时提交预订请求时，两个请求可能同时查到“没有记录”，然后同时插入成功，会议室就超卖了。
解决办法有两个层面。第一层是数据库约束，在预订表上建唯一索引，索引字段是会议室ID、开始时间、结束时间。这样就算代码逻辑有漏洞，数据库也能把重复数据挡住。第二层是业务校验，查询时把时间段改成“是否存在开始时间小于新结束时间且结束时间大于新开始时间的记录”，也就是区间重叠判断。这两个一起用，基本能杜绝并发问题。
还有个容易忽略的点是状态校验。会议室有“已预订”“使用中”“已结束”“已取消”这些状态，用户在订会议室时，必须检查当前时间是否已经过了预订的开始时间，如果过了就不能再取消，否则会出现“人还没到会议室，预订却已经被取消了”的尴尬情况。这块逻辑我在项目里单独抽了一个 BookingStatusUtil，所有状态判断都走这个工具类，避免各处散落一堆 if else。
3.3 设备报修模块：从提交到闭环的全流程实现
设备报修这个模块，看着简单，但真正做下来你会发现它其实是一个小型工单系统。用户提交报修单，管理员审核派单给维修人员，维修人员处理完后回填处理结果，用户确认后工单关闭。中间每一步都要记录时间和操作人，方便后续追溯。
我在设计表的时候，报修单里除了基础信息（设备名称、故障描述、报修人、报修时间），还加了当前状态、处理人、处理时间、处理结果这几个字段。状态机的流转我放在了 Service 层统一控制，不允许前端直接传状态值来修改。举个例子，用户提交报修时，前端只能传故障描述和设备编号，状态只能由后端初始化为“待审核”，前端把状态字段传进来也无效，这样能防止有人绕过流程直接改状态。
在权限控制上，报修模块也很有代表性。普通员工只能查看自己提交的工单以及提交新工单；管理员能看到所有工单并且能派单；维修人员只能看到分配给自己的工单。这种“数据级权限”用 Spring Data JPA 的 Specification 或者 MyBatis 的注解动态 SQL 都能实现，核心思路是先获取当前登录用户的角色，再根据角色拼接查询条件。
3.4 考勤统计模块：数据从哪来、怎么算
考勤模块是我在做这个项目时纠结最久的部分，因为“打卡”这件事涉及的数据来源五花八门。有的人脸识别打卡机，有门禁系统记录，还有钉钉和企业微信的打卡数据。真实企业里，数据往往分散在多个系统里，需要统一采集。
这套系统里我采用的方案是“手动补录 + 每日统计”。系统提供一个管理端的考勤数据导入接口，管理员可以从打卡机导出 Excel，然后上传到系统，系统解析后写入考勤原始记录表。每天晚上通过定时任务扫一遍当天的记录，计算每个人的上班时间、下班时间、迟到时长、早退时长，生成考勤汇总表。
这个设计虽然简单，但有个坑特别值得说：时区问题。Java 的 LocalDate 和 LocalDateTime 处理不好，很容易出现“导入的日期比实际日期早一天”或者“晚一天”的问题。我的经验是，Excel 解析时统一处理日期字符串，不要直接让 POI 自动转换类型，否则 2024-05-06 这种文本单元格可能被解析成 2024-05-05T12:00:00。所有日期字段在与数据库交互时，用 LocalDate 接，用 String 中转，反而最稳。
3.5 Spring Boot 常规配置：数据源、MyBatis、文件上传
这些基础配置虽然不复杂，但是配置错了会浪费大量时间，我把常用配置直接贴出来，照着抄就能用。
数据源连接池我用的是 HikariCP，Spring Boot 2.x 默认就是它，不用额外引入依赖。配置的时候核心参数是 maximum-pool-size 和 minimum-idle，单机小系统一般设置 10 和 5 就足够了。连接超时时间我设置了 30000 毫秒，初始化失败重试次数设为 1，避免数据库没起来时应用疯狂重试把日志刷爆。
MyBatis 的配置主要是驼峰命名映射和 SQL 日志。项目里我习惯用注解方式写简单 SQL，复杂查询用 XML。baseMapper 是 MyBatis-Plus 提供的通用方法，单表操作用它非常省事。要注意的是 XML 文件存放路径，默认是在 resources/mapper 目录下，如果你放到其他位置，需要在 application.yml 里指定 mapper-locations。
文件上传这块主要是会议室照片、公告附件这些东西。我配置了 multipart 的 max-file-size 为 10MB、max-request-size 为 20MB，文件存储路径使用相对路径，上传后把文件 URL 存进数据库，而不是直接把文件写进数据库字段里。文件存数据库的问题一是在数据量大的时候拖垮数据库性能，二是备份恢复非常麻烦。
4. 从零跑通项目：实操过程与关键代码
4.1 项目初始化与依赖引入
这里我直接演示一把比较通用的做法。新建一个 Spring Boot 工程时，用 Spring Initializr 生成，注意选择 Java 8 或 11、Spring Boot 2.7.x 版本，然后在 pom.xml 里加依赖。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>Lombok 要单独说一句。很多人觉得用了 Lombok 项目就不“正规”，但我个人非常推荐在毕设和内部项目中用，@Data、@Builder、@NoArgsConstructor 这几个注解能省掉大量样板代码。不过要注意，Lombok 在不同 JDK 版本下需要对应的版本，JDK 8 用 1.18.20 及以上都行，JDK 17 就要用最新版。
4.2 统一返回结果与全局异常处理
接口返回格式一定要统一，这是我做项目以来吃过亏之后总结的教训。如果每个接口的返回格式都不一样，前端联调时就要为每个接口写适配，代码非常丑陋。
我这边定义了一个 R 类，泛型设计，包含 code、message、data 三个字段。code 为 200 表示成功，500 表示系统异常，401 表示未认证，403 表示无权限。前端拿到 code 不是 200 就直接弹 message，不用解析 data。
全局异常处理用 @RestControllerAdvice 和 @ExceptionHandler。单独处理业务异常和系统异常。业务异常是项目里自定义的 BizException，主要是参数校验失败、业务状态不允许等场景；系统异常是 NullPointerException 那些，返回给前端的 message 统一是“系统繁忙，请稍后重试”，避免把敏感信息暴露给用户。
有一点值得注意：Spring Security 抛出的 AccessDeniedException 不会走到 @ExceptionHandler，要在 Security 配置里手动处理认证失败和权限不足的响应。这个坑我刚开始做的时候死活没想明白，后来才搞懂，过滤器链的异常根本到不了 Controller 层的全局异常处理器。
4.3 会议室预订的核心代码实现
把最核心的区间重叠校验逻辑贴出来，这段代码是整个会议室模块的灵魂。
public boolean checkBookingConflict(Integer roomId, LocalDateTime startTime, LocalDateTime endTime) { LambdaQueryWrapper<BookingRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(BookingRecord::getRoomId, roomId) .eq(BookingRecord::getStatus, BookingStatus.BOOKED.getCode()) .and(w -> w.lt(BookingRecord::getStartTime, endTime) .gt(BookingRecord::getEndTime, startTime)); return this.count(wrapper) > 0; }这个查询的逻辑其实就是“两条记录的时间段有交集”的标准判断：一条记录的开始时间小于你预订的结束时间，同时这条记录的结束时间大于你预订的开始时间。只要查出来数量大于 0，就说明时间段冲突。
为什么不用“开始时间等于你开始时间”这种等值比较？因为用户预订 9:00 到 10:00，另一个人预订 9:30 到 11:00，这两条记录的起止时间完全不相等，但明显冲突了。所以区间重叠判断是唯一正确的写法。
预订成功后，我用一个定时任务每 5 分钟检查一次会议室的预订状态，如果当前时间超过预订的开始时间，就把状态从“已预订”更新为“使用中”；超过结束时间，就更新为“已结束”。这个定时任务用 Spring 自带的 @Scheduled(cron = "0 */5 * * * ?") 就行，不需要引入 Quartz。
4.4 前端核心页面与联调细节
前端我用 Vue 2 + Element UI 做的，一个典型的管理后台布局：左侧菜单栏，右侧内容区。路由守卫里我做了权限控制，未登录的用户访问任何页面都重定向到登录页，已登录的用户访问无权限页面时提示“无权访问”。
和前端联调时最大的坑是跨域问题。我用 Spring Boot 作为后端服务跑在 8080 端口，前端开发服务跑在 9528 端口，浏览器直接发起 AJAX 请求会被同源策略拦截。解决办法有两个：一个是在后端写一个 WebMvcConfigurer 的 CORS 配置类，允许所有跨域请求；另一个是生产环境用 Nginx 反代，把前端和后端放在同一个域名下面。我在开发环境用的是第一种，把 allowCredentials 和 allowedOriginPatterns 都配置好，避免因为 allowedOrigins 为 * 导致 Cookie 丢失。
登录状态我用 Token 方案，登录成功后后端返回一个 UUID 作为 Token，存到 Redis 里，key 是 token，value 是用户ID，失效时间设为 2 小时。前端每次请求都在 header 里带 X-Token，后端写一个拦截器，从 Redis 里查这个 Token，查不到就返回 401，查到就把用户信息放进 ThreadLocal，供业务代码取当前用户。
5. 典型问题与排查实录
5.1 数据库连接报错：时区问题
这个属于新手必踩的坑。Spring Boot 2.x 连接 MySQL 8.x 时，如果没有在 JDBC URL 上加 serverTimezone=Asia/Shanghai，启动会直接报错：The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。
这是因为 MySQL 8.x 的默认时区设置不再兼容旧版本驱动。解决办法是在 application.yml 的数据库连接地址后面加上参数，同时把 useSSL 设为 false 避免自签名证书告警。
5.2 MyBatis-Plus 字段自动填充失效
我的项目里用了 @TableField(fill = FieldFill.INSERT) 希望创建时间字段自动填充，但测试时发现插入的记录 create_time 一直是 null。
问题出在没写 MetaObjectHandler 的实现类。MyBatis-Plus 的自动填充功能是一个钩子，只有你把 handler 配置到 Spring 容器里才会生效。我写了一个 MyMetaObjectHandler 类，重写 insertFill 和 updateFill 方法，把 LocalDateTime.now() 塞进去，问题解除。
这个坑说明一个道理：用了框架不能只看文档开头，自动填充这种“看似简单但必须配钩子”的功能，最容易踩空。
5.3 接口参数校验不生效
我在实体类的字段上加了 @NotBlank(message = "部门名称不能为空")，但请求进来后校验完全没起作用。
找了一圈原因发现，主要是缺了三个东西：
- 实体类上要加 @Validated 或者方法参数上加 @Valid
- 依赖里要加 spring-boot-starter-validation
第一点我在 Controller 里改了之后，报了一个错，这才发现第二个问题——项目里根本没有引入校验框架的依赖。Spring Boot 2.3 之后这个依赖不再默认提供，必须手动加，这个我写下来就是为了提醒大家：新版本框架的默认行为变化是最容易踩坑的地方。
5.4 前端请求后端返回数据中 LocalDateTime 格式不对
接口返回的 LocalDateTime 字段格式是 "2024-05-06T10:30:00"，前端 Element UI 的表格组件没法直接展示成想要的格式。
解决方式有二。第一种是后端在 JSON 序列化时统一格式化，在配置类里配置 Jackson 的 ObjectMapper，设置 LocalDateTime 的序列化格式为 "yyyy-MM-dd HH:mm:ss"。第二种是前端用 dayjs 或者 moment.js 格式化。我偏向第一种，因为后端做了格式化之后，所有调用方都受益，不用每个前端页面写一遍。
5.5 权限控制漏洞：越权访问
这个是最严重的逻辑问题。我测试的时候发现，一个普通员工登录后，如果把浏览器地址栏手动改成 /admin/user/list，竟然能直接访问管理员接口。
原因是我在 Security 配置里只写了对静态资源和登录接口的放行，对业务接口用了 @PreAuthorize 注解做方法级鉴权，但漏掉了对所有 /admin/** 路径的拦截。后来我把权限校验改成“路径规则 + 方法注解”双保险，同时在 Controller 里对当前用户做校验，确认当前用户的操作权限范围，才把这个漏洞补上。
这里也想多说一句：权限测试光靠“点一遍页面”根本不够，一定要手动构造请求去试，尤其要试“低权限用户访问高权限接口”这个场景。越权漏洞在面试里被问到的概率非常大，你能讲清楚你的系统怎么防越权，本身就是加分项。
5.6 会议预订并发冲突怎么复现与解决
这个问题我在前面设计时提到过，但这里把排查过程说完整。我先用 JMeter 起了两个线程池，每个线程池各 30 个并发，同时对同一个会议室同一时间段发送预订请求。第一次测试，数据库里插入了 43 条重复记录，并发冲突直接爆了。
处理方式分两步走。先用唯一索引兜底，确保同一会议室同一时间段只能有一条有效预订记录。MyBatis 插入时捕捉 DuplicateKeyException，把它转成业务异常，提示“该时间段已被预订”。然后再检查业务代码的校验逻辑，发现事务方式不正确导致查询和插入操作分离了，两个请求都读到空才导致重复插入。于是我在 Service 层方法上加上 @Transactional 隔离级别设置为可重复读，配合唯一索引拦截重复。
这个案例也正好说明了“技术方案不能单点依赖”，数据库约束、事务控制、代码校验三层都做到位，才能保证真实环境下系统不出篓子。
6. 项目扩展思路与面试经验
“智能办公室管理系统”听起来像是一个已经做烂的方向，但细想一下，国内大量中小企业的办公管理还停留在非常原始的状态，很多东西并没有被真正做好做成产品。所以哪怕只是作为一个课程作业或毕设，它依然有较大的发挥空间。
如果时间允许，我特别建议在现有基础上加这几个扩展点。把考勤数据接入企业微信打卡记录，把设备报修接上钉钉的消息通知，会议室门口放一个平板做扫码签到，或者把工位热度做成可视化看板——这些方向其实都不难，但会让项目立刻有一种“真在解决实际问题”的感觉。这比上来就堆一堆 Redis、MQ 但业务逻辑稀烂要更有说服力。
面试时，如果这个项目是你的主力项目，我建议多准备这几个视角的追问。你为什么用 RBAC 不用单一权限字段，会议室并发冲突怎么防止的，统计报表的 SQL 大概怎么写的，如果用户量和数据量翻十倍系统哪里会先扛不住。我见过太多人项目做完了但讲不清“为什么这么选”，这其实比项目本身做得漂亮还重要。
从我个人的实操体会来说，这个项目最值得投入时间的地方不是把功能做得多全，而是把几个核心模块锤扎实。会议室的并发和状态机、工单的流程流转、权限的精细控制，任何一块能讲明白，面试官都会比较认可。剩下的功能，能做到完整的增删改查，就已经是一个合格的 Spring Boot 管理系统了。
最后再分享一个小技巧：写这个项目时，多记一些开发日志，尤其是踩坑的记录。面试官问“项目中遇到最大的困难是什么”的时候，你直接甩出一个真实可复现的技术问题以及排查过程，比背十句“我负责了XX模块”都管用。这个项目做完，你会发现自己对 Spring Boot、MyBatis-Plus、Spring Security 的理解能上一个层次，而对业务流程和数据设计的敏感度，才是这套源码带给你最值钱的东西。
