企业官网建设流程全解析

选校园后勤报修作为毕业设计题目，其实是个很聪明的选择。这类系统麻雀虽小五脏俱全，既有用户端、管理端、维修端的角色划分，又有完整的工单生命周期，还能把文件上传、权限拦截、状态机流转这些SpringBoot常考的技术点全都串进去。一个题目做下来，Java基础、框架使用、数据库设计、前端配合基本都覆盖了，答辩的时候也有充足的内容可以讲。这篇文章就完整拆解一下这个基于SpringBoot+Vue的前后端分离报修工单系统，从架构设计到数据库表结构，从核心流程到部署细节，全部过一遍。

1. 项目整体设计与技术选型的思路拆解

1.1 这个毕设到底解决什么问题

宿舍楼的报修场景，本质上是一个“提交—派单—处理—反馈”的流程管理问题。学生发现灯坏了、水龙头漏水、空调不制冷，以前的方式是去宿管那里填纸质单子，或者打电话报修，然后维修工什么时候来、来不来、修没修好，完全靠运气。这套系统要解决的核心痛点就三个：报修信息数字化、维修过程可视化、考核数据可量化。

从毕设的角度看，这个题目比单纯做一个CRUD增删改查要有含金量得多。它天然带有“流程”属性，工单不是一条简单的数据记录，而是在不同角色之间流转、状态不断变化的对象。这就逼着你必须去设计状态流转逻辑、处理不同角色的权限边界、考虑并发场景下的数据一致性。这些内容写进论文里，评审老师一眼就能看出工作量和技术深度。

另外一点很实际：校园报修这个场景，答辩的时候老师非常熟悉。他不需要你花大量时间解释业务背景，可以直接切入技术实现，这意味着你的项目亮点更容易被get到。相比做一个虚构的电商系统或者管理系统，报修工单系统的业务逻辑更清晰，边界更明确，适合在有限时间内完成并做扎实。

1.2 为什么选SpringBoot+Vue这套组合

技术选型这块，SpringBoot + Vue + MySQL这套组合基本是当前Java毕设的标配，但标配不等于平庸，关键在于你怎么把这个组合用出深度。

后端选SpringBoot的理由很充分。第一，它极大降低了Spring的配置成本，通过自动配置和起步依赖让项目快速跑起来，这对毕设周期来说是刚需。第二，SpringBoot生态里有一堆可以直接用的场景解决方案，Spring Security做认证授权、MyBatis-Plus做数据访问、MinIO做文件存储，这些不是玩具级demo，而是工业界真实的常用方案，写进简历经得起追问。第三，SpringBoot内置的依赖管理和打包机制简化了部署流程，打完jar包扔服务器上就能跑，对后面部署演示非常友好。

前端选Vue则是照顾到了“前后端分离”这个关键词。Vue的组件化开发方式让页面逻辑清晰可维护，Element UI组件库能快速搭建出像样的管理界面，而Vue Router和Axios分别解决路由和接口请求问题。最实在的是，Vue的学习曲线比较平缓，即便你之前只写过jsp或者纯HTML，花两周时间也能熟练上手。

1.3 前后端分离架构里那些容易踩坑的细节

前后端分离听起来高大上，但实际做起来有几个关键点必须处理好，否则开发过程中会非常痛苦。

跨域问题是第一个坎。前端跑在8080端口，后端跑在8081端口，浏览器会拦截跨源请求。解决办法是在后端配置CORS，或者用反向代理。实践中我更推荐在后端项目里加一个WebMvcConfigurer配置类，统一处理跨域，这样本地开发调试时最省事。如果图省事直接用@CrossOrigin注解，也能用，但每个Controller都得加，不够优雅。

第二个关键在于接口文档的约定。前后端分离模式下，前端和后端是并行开发的，接口地址、请求参数、返回结构必须提前约定清楚。我自己习惯定义一个统一的返回类，比如Result ，里面固定包含code、message、data三个字段。所有接口都返回这个结构，前端只用处理一种数据格式，判断code是否为200即可。这样写还有一个好处：方便统一处理token过期、权限不足等异常情况。

再就是token认证机制。用户登录成功后，后端生成JWT返回给前端，前端把token存在localStorage里，每次请求通过Axios拦截器在请求头加上Authorization字段。后端再用SpringBoot的拦截器或者Filter校验token，放行白名单之外的接口都要验证身份。这个地方是毕设答辩的高频考点，一定要弄清楚整个流程的每个环节，包括token什么时候生成、什么时候校验、过期了怎么处理。

2. 核心功能模块与数据库设计拆解

2.1 三种角色和权限控制策略

报修系统的用户角色可以拆成三类：学生（普通用户）、维修工、管理员。有些方案还会拆出宿管角色，但核心流程三种角色足够了，角色越多代码工作量越大，对毕设来说性价比不高。

学生端的功能是：提交报修单、查看自己报修单的处理进度、对完成的工单进行评价、维护个人资料。维修工端的功能是：查看分配给自己的工单列表、更新工单处理状态、填写维修结果和耗材使用情况。管理员端的职责最重：对所有工单进行派工操作、管理用户和维修工信息、查看统计数据、处理超时工单。

权限控制方案推荐使用Spring Security + JWT的组合。登录接口放行，其他接口统一拦截。获取当前登录用户信息可以从JWT中解析出userId，然后查询数据库得到完整用户信息和角色。在Service层做权限判断，比如维修工只能查询assignee是自己、且role是维修工的工单。这里有一个实操经验：光靠前端隐藏按钮是不够的，后端每个接口必须做权限校验，可以自定义一个@RequireRole注解配合AOP实现，代码会清爽很多。

2.2 工单状态流转是系统的灵魂

工单状态设计得好不好，直接决定了系统复杂度和用户体验。我把报修工单的状态定义成五个：待派工、待维修、维修中、已完成、已取消。

状态流转的规则是：学生提交工单后进入待派工状态；管理员看到待派工工单后进行派工，指定某个维修工，工单变为待维修；维修工接单后状态变为维修中；维修完成填写结果后状态变为已完成；在待派工状态时，学生可以取消工单。这套状态机的设计要点是，每个状态转移必须要有明确的触发者和触发条件，不允许随意跳转。

数据库层面的实现方式是维护一个status字段，用数字或枚举表示状态。更严谨的做法是额外记录状态变更日志表，每次状态变化都插入一条记录，包含操作者、操作时间、原始状态、目标状态、备注信息。虽然不是必须的，但如果论文里能写出这个扩展，会显得考虑问题更全面。

2.3 数据库表结构设计要点总结

数据库设计是毕设中最直观的加分项，表结构设计得合理，写到论文里很漂亮，评审老师一眼就能看出你的数据库功底。整理一下这套系统最核心的几张表：

用户表需要包含id、username、password、real_name、phone、role、avatar、create_time、status等字段。密码必须用BCrypt加密存储，明文存密码在答辩时会被直接指出安全问题。角色用字符串存，加一个索引。

报修工单表是最核心的表，字段包括id、order_no、user_id、title、description、location_building、location_room、category、images、status、assignee_id、create_time、finish_time、remark。这里有几个设计细节：一是order_no工单编号，用时间戳加随机数生成，方便用户报修后凭单号查询；二是location信息单独存省得以后扩展麻烦；三是images存储的是图片URL列表，用JSON字符串存，也能用逗号分隔，但JSON格式解析起来更方便。

维修记录表保存维修工填写的结果，包括id、order_id、assignee_id、solution、used_materials、cost_materials、result_images、create_time。评价表用于评价维修工服务，字段包含id、order_id、user_id、rating、content、create_time。这两张表让工单状态与评价解耦，符合数据库设计规范。

还有几张辅助表，比如系统通知表、操作日志表，属于锦上添花但性价比很高，因为论文里“表结构设计”这一章会因此显得非常充实。所有表的字段类型、注释、索引设计也值得认真打磨，例如status字段用tinyint存储、时间字段用datetime、description用text类型，这些都是基本的规范要求。

3. 关键业务流程与接口设计实战

3.1 报修工单创建到派工的完整链路分析

从学生提交报修单到管理员完成派工，这条链路是整个系统最核心的流程。分解下来一共五个步骤：学生填写并提交报修表单，后端接收数据并保存工单记录；系统自动生成工单编号，并设置状态为待派工；工单出现在管理员的待办列表中；管理员在列表页查看工单详情，选择维修工进行派工；系统更新工单状态和指派人，同时生成一条通知记录推送给维修工。

这一步给学生的体会是，系统的每一段流程都要前置思考数据变化。例如工单提交之后，如果管理员长时间不派工，系统怎么提醒？我为了毕设展示又额外加了超时提醒，实现方式是定时任务扫描超过X小时还在待派工的工单，向管理员发送站内信提醒。这个扩展本身代码量不大，但“及时性”的问题在真实业务中很重要，写进论文里会体现你做系统的严谨度。

涉及的接口主要有createOrder提交报修单、listPendingOrders获取待派工列表、assignOrder执行派工。有个易错点要注意：派工接口必须做并发保护，防止两个管理员同时给同一个工单指派不同的维修工。最简单的做法是使用MySQL的行锁，在更新语句里加上条件“where status = 待派工”，更新成功才说明抢到了派工权。

3.2 维修处理到完成的闭环逻辑

维修工登录后看到的工单列表分为两部分：待接单和已完成。点击接单后工单从待维修变为维修中，然后维修工填写维修结果时除了写文字描述，还需要上传维修前后的照片。完成状态回写后，学生端就能看到已完成工单，并弹出评价入口。

这个闭环里有个关键细节，就是状态回写的原子性。维修工点击“完成工单”这个按钮，后端要做的操作不止是改成已完成状态，还包括写入维修记录表、更新工单完成时间、生成一条通知给学生。这些操作必须在同一个事务里完成，用@Transactional注解保证要么全部成功要么全部回滚。很多毕设里出现问题就是事务边界控制不好，导致工单状态变了但维修记录没写，数据对不上，排查起来相当崩溃。

3.3 评价机制和消息通知的实现方式

评价机制设计得简单一点，学生只能对已完成的工单进行评价，用1到5星的评分加一段文字内容。从数据层面来说，评价表和工单表是一对一的关系，为了避免重复评价，要在评价表里给order_id加唯一索引，从数据库层面做兜底。

消息通知这块，最轻量又实用的方式是站内信模式。建一张notification表，字段包含target_user_id、content、is_read、create_time。当工单状态发生变化时，往这张表插入一条记录，用户在系统顶部导航栏就能看到未读消息数量。不推荐在这个毕设里引入WebSocket或者消息队列，虽然那些技术听起来很炫，但会给系统带来不必要的复杂度，而且答辩时如果被问到底层实现，准备不充分反而减分。

4. 前端页面与后端接口对接的实战要点

4.1 Vue项目结构和核心页面设计

前端项目结构建议用Vue CLI或者Vite创建脚手架之后按模块组织，大致包含views页面目录、router路由目录、store全局状态目录和api接口封装目录。页面部分核心的有：学生端报修表单页、工单列表页、工单详情页；维修工端工单中心页、接单操作页；管理员端全量工单管理页、派工工作台、用户管理页、数据统计页。

页面设计上最忌讳的是“控件堆砌”。报修表单页尽量分组呈现信息：故障位置、故障类型、故障描述、图片上传，每个字段都要有校验规则，例如图片大小限制在5MB以内，描述文字不能少于10个字符。管理员端工单列表页要支持多条件筛选，比如按状态、按时间范围、按故障类型，更进一步可以加入一个搜索框按工单号或者学生姓名模糊搜索。

4.2 前后端联调容易出的三类问题

第一类是字段命名风格不一致问题。后端Java习惯用驼峰命名，比如createTime，前端JavaScript虽然也是驼峰，但如果你做的是小写开头，或者后端直接把字段返回成下划线风格，前端解析时非常容易出错。解决办法是全程统一用驼峰命名，并在后端实体类上使用@JsonProperty注解做映射。

第二类是日期时间格式问题。后端默认返回的Java时间格式是ISO字符串，前端要显示成yyyy-MM-dd HH:mm:ss这种样式，需要用工具类做格式化。建议后端直接在实体类的时间字段上加@JsonFormat注解，固定好输出格式，前端就省掉这个处理的麻烦。

第三类是文件上传功能的兼容性问题。这个系统的图片上传思路是：前端把文件上传到MinIO，拿到URL后把URL字符串存进工单表。这样做的好处是工单的增删改查都只处理字符串，和文件服务解耦。需要注意的一点是MinIO的Bucket权限要设置为公共只读，否则你存进去的URL前端根本打不开图片。

4.3 前端权限路由和后端接口拦截的组合策略

路由权限控制的常见做法是，在登录成功后路由表根据用户角色动态生成。学生端只能访问报修、评价相关页面，维修工端只能访问工单处理相关页面，管理员看到的则是全量管理路由。Vue Router有一个路由守卫beforeEach钩子，用来在跳转前校验登录状态和路由权限，这个环节非常值得仔细设计。

后端对应的逻辑是，在SpringBoot的HandlerInterceptor里写一个继承HandlerInterceptorAdapter（Spring Boot 2.x）或实现HandlerInterceptor接口（Spring Boot 3.x）的类，实现preHandle接口。这个拦截器处理的是token验证与权限判断。把需要放行的接口放置在白名单里，其他接口全部走token校验。前端的路由守卫和后端的接口拦截是两道防线，前端管交互体验，后端管数据安全。这个配合逻辑在毕设论文里一定要写清楚，因为这是“前后端分离”和“权限设计”两个核心关键词的重要结合点。

5. 部署上线与文档撰写经验总结

5.1 从本地环境到云服务器部署的完整流程

本地开发的标配环境是：JDK 1.8或11，Maven 3.6+，MySQL 5.7或8.0，Redis可装可不装，Node.js和npm用于前端构建。后端项目通过mvn clean package命令打成可执行jar包，前端项目通过npm run build生成dist目录的静态文件。

部署方案我推荐两种。方案一最省事，买一台云服务器，装好JDK和MySQL，把jar包和前端dist目录通过nginx分别部署。配置nginx把域名的/api路径转发到后端8080端口，其他路径指向前端静态文件。这样做的好处是浏览器访问时不会出现跨域问题，因为前后端在同一个域名下，可以省掉CORS相关配置。

方案二更适合在答辩现场演示时使用，就是后端直接java -jar命令跑在服务器上，前端本地开发服务器临时跑起来指向后端接口。好处是方便随时改代码刷新页面，现场演示更灵活。坏处是演示的时候电脑不能断网，远程服务器和数据库的连通性也必须是好的，现场容易出状况。

部署时最常踩的坑是MySQL数据库编码问题。创建数据库时务必指定utf8mb4字符集，否则前端传过来的中文存进数据库后会变成乱码。另一个坑是时区问题，JDBC连接串里加上&serverTimezone=Asia/Shanghai，否则会出现时间比正常晚8小时的情况，这个现象非常容易在展示工单完成时间时被发现。

5.2 毕设论文架构和答辩准备的实战建议

论文结构按常见的写法大致是：绪论（研究背景与意义、国内外研究现状）、相关技术介绍、系统分析（可行性分析、需求分析）、系统设计（总体架构设计、功能模块设计、数据库设计）、系统实现（开发环境、核心功能实现）、系统测试（测试方法、测试用例、测试结果）、总结与展望。数据库设计部分把ER图和建表SQL放进去，系统实现部分贴核心代码并配上详细文字说明，页面的功能截图也放上更直观。

答辩准备时，一定要能清楚地说明几个核心问题：工单状态机的流转逻辑如何实现、JWT认证的原理、为什么选MyBatis-Plus做数据持久层、如果并发量变大了架构如何优化。这些追问概率极高，说不清楚会被看成“只会复制粘贴”。可以把System.out或日志里打印的关键执行过程提前截图保存，在演示时展示出来，能有效证明代码确实是能跑通的。

6. 常见问题与排查技巧速查

6.1 后端常见报错速查表

6.2 前端联调时的几个关键排查方法

前端报错最常见的是无法获取到后端数据，这时候不要急着怀疑后端有bug，先看控制台打印出的Network面板，确认请求是否有发出、返回的HTTP状态码是什么、响应的JSON结构是否符合预期。浏览器控制台上红色的Axios错误信息大部分都会明确指出是跨域、404还是500，这个信息比任何猜疑都直接。

如果接口返回的结构和后端代码不一致，多半是实体类的序列化出现了问题。可以先把实体类的toString方法重写好，可以方便查看实体类的字段值，或者在Controller层增加一个返回JSON的接口，用curl测试看原始输出。

还有一个实操小技巧：在Axios的拦截器里统一打印请求地址和参数、响应数据和错误信息。开发阶段这个日志极大节省定位时间，上线的时候再统一关闭，成本极低收益很高。

我个人在实际操作中最大的体会是，这类工单系统的成败关键不在某个单一技术点，而在于整个流程的闭环严谨性。任何一个状态更新操作如果你没有考虑并发、缓存和事务，工单都可能产生异常数据，这会消耗大量联调时间。另一个体会是，做这种系统千万不要追求功能堆砌，把核心流程做扎实、状态流转做严谨、权限控制做完整，比硬加三五个边缘功能要好得多。对于还没开始动工的同学，建议先把工单状态机和数据库表结构画顺了再写代码，思路清晰了后面基本就是体力活。