企业官网建设流程全解析

宿舍报修这事儿，看着小，管起来真的让人头大。学生报修靠跑腿登记，维修师傅拿着纸质单子到处转，管理员想查进度只能挨个打电话问。我去年帮某高校后勤处搭过一套类似的维修管理流程，深刻体会到传统方式的痛点：报修信息丢单、维修响应慢、工单状态不透明、事后统计全靠拍脑袋。所以看到"基于SpringBoot+Vue的宿舍维修管理系统"这个题，我第一反应就是——这确实是很多高校、企业宿舍区都在刚需的东西。这篇博文我会从系统需求拆解、技术选型理由、数据库设计、后端核心实现、前端交互闭环到部署联调踩坑，把一套可复用的完整实现思路讲透。

这套系统做出来能干什么？简单说就是三条线：学生线上提交报修，维修师傅接单处理并回填结果，管理员派单监督和做数据统计。技术栈是SpringBoot + Vue + MySQL + MyBatis，前后端分离，能学到的东西非常实在——从零把一个业务系统拆成模块、设计表结构、写接口、对页面。无论你是拿它做毕业设计、课程设计，还是想参考一套完整的JavaWeb实战项目，这篇都能给你一个可以直接参照的路线图。

1. 报修管理场景里的核心需求拆解：是谁在用、要解决什么

很多做管理系统的人有个通病——上来就建表、写CRUD，做完发现根本没人用，因为业务逻辑压根没捋清楚。做宿舍维修系统也一样，第一步不是写代码，是搞清楚这个系统里到底有几类人、每类人的痛点是什么、系统要替他们解决什么问题。

1.1 三类用户画像与各自的"愤怒点"

宿舍维修管理系统里的用户，往细了分至少三类：

• 学生（报修人）：他们的核心诉求是"报修快""有人管""能知道修没修"。传统方式里，报修要手写登记或者打电话，师傅来不来、什么时候来全看运气，修完没人通知，体验很差。
• 维修师傅：核心诉求是"任务清晰""路径合理""别让我白跑一趟"。纸质派单的方式下，师傅经常跑错楼栋、重复跑路、材料没带够，而且干没干活、干了啥活没有记录，月底结算扯皮。
• 管理员（后勤/宿管）：核心诉求是"全局可视""进度可控""绩效可算"。以前全靠电话和Excel，一个宿舍区一天几十单报修，谁处理了谁没处理根本盯不过来，月底想统计个水电维修占比都要手工数半天。

这三类人的需求就是系统设计的"原始需求文档"。很多课程设计只做一个"管理员端+用户端"就完事，但真要落地的话，维修师傅端必须独立出来，否则师傅只能靠管理员把单子打印出来再拿去干活，那就白做了。

1.2 核心业务流程：一张工单的生命周期

系统的灵魂是一条工单状态流转线。我梳理下来的核心流程是：

1. 学生提交报修单，填写宿舍楼栋、房间号、报修类型（水电/门窗/设备/其他）、问题描述、预约时间、上传图片。
2. 管理员在后台看到新报修，进行派单——可以手动指定某个维修工，也可以按技能标签自动匹配。
3. 维修师傅在APP端/PC端看到分配给自己的工单，确认接单，去现场处理。
4. 师傅完工后填写"处理结果"（维修内容、是否更换配件、耗时），工单状态变为"待验收"。
5. 学生确认维修效果，进行评价（满意/不满意 + 评语）。
6. 管理员随时可以筛选状态、看超时单、导出统计报表。

注意这里有个关键点：报修单不是提交完就结束了，中间有"已接单""维修中""待验收"等多个状态，每个状态对应不同的可操作者和可见按钮。这个状态机的设计直接决定了系统逻辑是否严密，我在后面专门讲。

1.3 功能清单：别贪多，先把主线闭环做完整

参考市面上的成品系统，很多都塞了一堆鸡肋功能。我给这个项目圈定的功能边界是：搞定报修闭环，再谈扩展。所以核心功能分为四个模块：

至于消息推送（WebSocket实时通知）、小程序端、配件库存管理这些，属于二期扩展。做毕设或者实战项目，先把红色主线打通比堆功能重要得多。

2. 技术选型逻辑：为什么是SpringBoot+Vue+MySQL+MyBatis这个组合

这套技术栈被众多课程设计和中小型项目选为标配，不是因为跟风，而是因为它确实适合"业务管理系统"这一场景。我拆开讲一下每个组件在这套系统里是干嘛的，以及如果换成别的方案会有什么差别。

2.1 SpringBoot：把繁琐配置关进笼子

早期做JavaWeb，用SSH（Struts+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）的时候，光配置XML就得写半天：数据源配置、事务配置、扫描配置、拦截器配置……每个配置文件还容易写错。SpringBoot把"约定大于配置"推向极致，内置Tomcat，一个启动类就能把Web应用跑起来。

对于这个系统，SpringBoot的价值不仅是开发快，更在于生态成熟。整合MyBatis、整合JWT认证、整合分页插件，官方都有非常成熟的starter或者第三方适配，不需要自己造轮子。而且以后项目上线部署，SpringBoot的fat jar直接java -jar就运行了，运维成本极低。

2.2 MyBatis：SQL可控，适合业务多变的管理系统

MyBatis和Spring Data JPA是Java持久层最常见的两个选择。我为什么选MyBatis而不是JPA？核心原因是：管理系统的查询条件太灵活了。

以报修单列表为例，管理员要按状态筛、按楼栋筛、按时间范围筛、按维修工筛，甚至组合筛选。用JPA写动态查询要拼接Specification，代码不够直观；用MyBatis写动态SQL，一个<where>标签加几个<if>就能把多条件组合查询写得明明白白。尤其报表统计要用到分组聚合SQL，MyBatis原生SQL的优势就更明显了。

再者，MyBatis的#{}预编译机制能有效防SQL注入，这也是很多传统企业选它的理由。不过要注意的是，${}拼接有注入风险，排序字段这类别用${}，宁可做个白名单映射。

2.3 Vue + Element UI：前后端分离的黄金搭档

Vue在国产管理系统里的统治力，很大程度归功于Element UI/Element Plus这套组件库——表格、表单、对话框、分页、日期选择器全都现成，长得也符合管理系统的审美。前端用Vue Router做页面路由，用Axios做HTTP请求，用Vuex/Pinia管理登录状态，一个标准的SPA（单页应用）就搭起来了。

前后端分离架构下，前端就干三件事：渲染（把后端JSON数据展示成表格/表单）、交互（用户点按钮发请求）、路由控制（根据角色判断能进哪个页面）。逻辑都在后端收口，前端不碰复杂业务规则，这样职责清晰，也很适合新手理解和维护。

2.4 MySQL：这个体量下最省心的选择

宿舍维修系统，数据量级撑死几千张工单、几百用户，MySQL单库单表完全足够。选MySQL的另一个考虑是环境常见：学校机房、个人电脑上装MySQL几乎零门槛，Navicat一开就能看数据调试，遇到问题了网上答案一搜一大把。不选Oracle（太贵太重度）、不选PostgreSQL（生态偏后，资料少），对中小型管理系统来说，MySQL就是那个"不会错"的选择。

3. 数据库设计的核心表结构与字段取舍心得

很多项目挂掉不是挂在代码上，而是挂在表结构设计上。这个系统的表不需要太多，六张表左右就能支撑完整的报修闭环。我把关键表结构思路写一下，顺便说说哪些字段是在实战中容易漏掉的。

3.1 用户角色与宿舍信息怎么组织

最基础的user表，除了用户名、密码、手机号，一定要有role字段（学生/维修工/管理员）。同时，因为报修单要关联宿舍楼栋和房间，student用户需要冗余building（楼栋）、room（房间号）字段，而不是单独建一张宿舍表再去关联——理由很简单：宿舍和学生的关系在这个场景下几乎是静态的，冗余一个字段能省掉一次联查，而且后续报修单里要展示学生宿舍信息也能直接查。

维修工角色建议加一个skill_type字段（擅长水电还是门窗），派单的时候可以做自动匹配。还有个很实用但容易被忽略的字段——current_status（空闲/忙碌），管理员派单前能直观看到谁手上还有活。

3.2 报修单主表：状态的数字字典化

repair_order是系统的主表，核心字段：

这里我特别想提两点：

第一，状态字段用int枚举而不用varchar字符串。存"待派单"还是存0？肯定存0。字符串可读性好，但扩展性差、容易拼写出错，而且数据库索引对int更友好。具体含义在Java代码里用常量类或者枚举类映射就行。

第二，要加deleted逻辑删除字段。学生误提交了报修单，或者管理员删除了无效工单，如果直接物理删除，数据统计和审计就断层了。逻辑删除虽然查询时要记得加where deleted=0条件，但换来的数据完整性是值得的。

3.3 评价表与其他辅助表

报修验收环节，学生要能评星评价，所以有一张repair_evaluate表，关联order_id、score（1-5星）、content（评价内容）、create_time。评价表和主表是一对一关系，为什么不把评价字段直接塞进主表？——因为主表查询频率高，如果每张单子都有5个评价字段，列表查询会多带很多用不到的数据；拆出来只在需要详情的时候查，反而更轻量。

另外如果要做管理员操作留痕，可以加一张operation_log表（操作人、操作类型、操作对象、操作时间、IP），这个对于毕设答辩加分挺重要的，老师一问"系统安全的可审计性在哪"，你就能直接怼出来了。

4. 后端实现的关键环节：状态机、权限拦截与MyBatis动态SQL

后端不是写一堆CRUD就叫实现了。这个系统里最有含金量的几个点——工单状态流转控制、登录鉴权、多条件查询——我一个个拆开讲。

4.1 统一返回结构与全局异常处理

前后端分离后，接口必须有一个统一的响应结构，我建议的格式很简单：

{ "code": 200, "message": "操作成功", "data": { } }

对应Java里一个泛型类Result<T>。所有Controller方法都返回这个类型，前端Axios响应拦截器里统一判断code，不是200就弹出message。这样做的好处是：前端不需要对每个接口单独做错误处理，全局收口，代码极其干净。

同时配合@RestControllerAdvice做全局异常捕获，业务异常抛一个BusinessException，未知异常兜底返回"系统繁忙"。这套组合几乎是SpringBoot项目的标配，但很多新手容易忽略——结果就是每个接口都写一堆try-catch，代码膨胀得没法看。

4.2 工单状态流转的控制逻辑（重点）

我见过不少项目里，工单状态的改变直接在前端按钮事件里改个数字就发到后端，后端接口完全不校验状态是否合法。结果就是：一个已经"已完成"的工单还能被维修工"接单"，逻辑全乱了。

正规做法是在Service层做一个状态机校验。比如定义合法的状态转换关系：

• 待派单(0) → 待接单(1)：管理员派单
• 待接单(1) → 维修中(2)：维修工接单
• 维修中(2) → 待验收(3)：维修工完工登记
• 待验收(3) → 已完成(4)：学生确认
• 待派单(0) → 已取消(5)：管理员回收/学生取消

在Mapper更新之前，先查一次当前状态，对比是否满足合法转换，不满足就抛业务异常"当前状态不允许该操作"。这样把不合理的状态流掐死在后端。

Service里可以用一个Map预定义转换规则：

private static final Map<Integer, List<Integer>> STATUS_TRANSITIONS = new HashMap<>(); static { STATUS_TRANSITIONS.put(0, Arrays.asList(1, 5)); STATUS_TRANSITIONS.put(1, Arrays.asList(2, 5)); STATUS_TRANSITIONS.put(2, Arrays.asList(3)); STATUS_TRANSITIONS.put(3, Arrays.asList(4)); }

更新的时候带上旧状态作为条件，用乐观锁的思路：

UPDATE repair_order SET status = #{newStatus} WHERE id = #{orderId} AND status = #{oldStatus}

这样即便两个请求同时打到后端，也只有一个能改成功，状态不会乱掉。

4.3 登录认证与角色权限的拦截策略

系统的登录认证我用JWT来实现，流程是：

1. 用户提交用户名密码，后端校验通过后生成一个Token（把用户ID和角色编码进去），返回给前端。
2. 前端把Token存到localStorage，每次Axios请求在请求拦截器里加上Authorization: Bearer <token>头。
3. 后端写一个拦截器（HandlerInterceptor），对非登录接口做Token解析，解析成功把用户信息放入ThreadLocal，失败返回401。

角色权限怎么控制？最简单有效的办法是在拦截器上加注解，比如定义@RequireRole("admin")，拦截器里判断当前用户角色是否匹配。或者直接把角色判断写在Controller方法里。规模不大时别上Spring Security那套，太重了，理解成本也高。

我推荐的做法是：拦截器只管登录状态，Controller层用自定义注解管角色权限，两行代码就能给关键接口加权限保护。

@GetMapping("/admin/orders") @RequireRole({"admin"}) public Result<List<OrderVO>> listAllOrders() { // 仅管理员可访问 }

4.4 MyBatis多条件查询的SQL写法

管理后台的工单列表，筛选条件可能有：状态、楼栋、报修类型、开始时间、结束时间。用MyBatis的动态SQL来实现，核心就是<where>和<if>的配合：

<select id="selectOrderList" resultType="com.example.vo.OrderVO"> SELECT o.*, u.name AS student_name, u.phone AS student_phone FROM repair_order o LEFT JOIN `user` u ON o.student_id = u.id <where> <if test="status != null"> AND o.status = #{status} </if> <if test="building != null and building != ''"> AND o.building = #{building} </if> <if test="category != null"> AND o.category = #{category} </if> <if test="startTime != null"> AND o.create_time &gt;= #{startTime} </if> <if test="endTime != null"> AND o.create_time &lt;= #{endTime} </if> AND o.deleted = 0 </where> ORDER BY o.create_time DESC </select>

这里<where>标签会根据条件自动去除最前面的AND，非常方便。再配合PageHelper做分页，三行代码就搞定。实测下来这种写法不管条件组合怎么变，都不需要改Java代码，非常稳。

5. 前端Vue实现要点：从搭建骨架到报修交互闭环

前端这部分我按"项目骨架→请求封装→核心页面→权限路由"四个层次来讲，每个层次都有关键的实操细节。

5.1 Vue项目的目录结构与状态管理

用Vue CLI或者Vite创建项目后，建议按模块组织目录：

src/ ├── api/ // 按模块封装接口请求 │ ├── order.js │ ├── user.js │ └── stats.js ├── assets/ ├── components/ // 公共组件 ├── router/ // 路由配置 ├── store/ // Pinia或Vuex状态管理 ├── views/ // 页面组件 │ ├── student/ // 学生端页面 │ ├── worker/ // 维修工端页面 │ └── admin/ // 管理端页面 ├── utils/ │ ├── request.js // Axios封装 │ └── auth.js // Token存取 └── App.vue

状态管理我建议用Pinia（Vue3）或者Vuex（Vue2），存储的核心数据只有两个：当前登录用户信息（名字、角色）、Token。千万别把接口数据往store里塞，列表数据放在页面组件自己的data里就行，刷新重新拉，逻辑简单不掉链子。

5.2 Axios封装的关键点：请求拦截器和响应拦截器

Axios封装是所有前端请求的入口，这里做得好，后续所有页面写起来都很舒服。核心逻辑：

// utils/request.js import axios from 'axios'; import { getToken, removeToken } from './auth'; import router from '../router'; const request = axios.create({ baseURL: '/api', // 开发环境走Vite代理，生产环境走Nginx timeout: 10000 }); // 请求拦截器：自动带Token request.interceptors.request.use(config => { const token = getToken(); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); // 响应拦截器：统一处理code request.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res.data; // 直接拿到业务数据，少一层 } if (res.code === 401) { removeToken(); router.push('/login'); return Promise.reject(new Error('登录已过期')); } ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); }, error => { ElMessage.error('网络异常，请稍后重试'); return Promise.reject(error); } );

有个细节我实战中踩过坑：响应拦截器里返回res.data还是返回整个res直接影响所有API调用的写法。我设计成直接返回res.data（也就是把code/message那层剥掉），所有页面里拿数据就是const list = await orderApi.getList(params)，非常清爽。

5.3 学生报修页面的完整交互设计

学生报修页面是整个系统使用频率最高的页面，交互设计上要下功夫：

• 宿舍信息自动带出：学生登录后，后端Token里已经带了宿舍楼栋房间，前端从登录用户信息里自动填充，不需要学生每次重复填。
• 报修类型用图标+文字卡片：水电/门窗/设备/其他，四选一，比下拉框更直观。
• 图片上传用Element的upload组件，限制单张5MB以内，传成功拿到URL再随表单提交。图片不直接塞进表单JSON里，而是先传到后端返回一个URL，这个策略要贯穿全项目。
• 问题描述给placeholder引导："请描述具体故障情况，方便师傅准备工具和配件"，能明显减少无效报修单。
• 提交后要跳转到"我的报修"列表，并给出明确反馈"报修单提交成功，维修师傅将尽快联系您"。

5.4 维修工和管理员页面：以工单卡片和看板为主

维修工端的核心页面是"我的工单"，推荐用卡片布局而不是表格——每张工单显示宿舍位置、报修类别、紧急程度、描述摘要，卡片右上角根据状态显示不同颜色的标签。按钮的显示逻辑用一个计算属性或者过滤器控制：

• 待接单 → 显示"接单"按钮
• 维修中 → 显示"完工登记"按钮
• 其他状态 → 不显示操作按钮

管理员端除了工单管理表格，Dashboard首页要放ECharts统计图：报修类型分布饼图、每周报修趋势折线图、维修工工作量柱状图。ECharts在后端给三个统计接口：

1. GET /api/stats/category→ 按类型分组计数
2. GET /api/stats/trend?days=14→ 按日期分组计数
3. GET /api/stats/worker→ 按维修工统计完成工单数

这三个接口都是简单的GROUP BY查询，前端拿到数据填进ECharts的option就能渲染。

5.5 路由守卫实现角色隔离

前端路由不能只做"页面存在"，要做"角色隔离"。比如/admin、/worker这些路径，学生账号访问了要直接重定向到403页面。实现方式：

router.beforeEach((to, from, next) => { const token = getToken(); if (!token) { if (to.path === '/login') next(); else next('/login'); return; } const user = getUser(); if (to.meta.roles && !to.meta.roles.includes(user.role)) { next('/403'); return; } next(); });

路由配置里给每个页面声明meta.roles，比如：

{ path: '/admin', component: AdminLayout, meta: { roles: ['admin'] }, children: [/* 子页面 */] }

这样角色的隔离不仅仅是"按钮隐藏"，而是直接进不去页面，逻辑上更安全。当然前端守卫只是体验优化，真正的权限控制必须以后端接口为准，前面已经讲过了。

6. 部署联调的实战踩坑：时区、跨域、图片路径与状态并发

这套系统从前到后跑通，最大的成本其实在联调阶段。我把自己实战中踩过的几个比较典型的坑列出来，每个都是花了时间才排查出来的，直接写出来帮各位省点功夫。

6.1 Jackson时区问题：前端时间少了8小时

第一个坑：数据库里的时间显示正常，前端拿到的时间却慢了8小时。原因很典型——SpringBoot默认的Jackson序列化时区是UTC，而我们的MySQL连接配置用了serverTimezone=Asia/Shanghai，两边不一致，导致JSON输出时时间被偏移。

解决办法是在application.yml里统一配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

加上之后，时间格式统一、时区统一，前端表格时间显示就正常了。

6.2 跨域问题：前端明明配了代理还是报错

前端开发环境访问后端接口，涉及到跨域。我推荐的做法是开发环境用Vite/Webpack代理，生产环境用Nginx代理，尽量不要在后端代码里写@CrossOrigin或者全局CORS配置开绿灯。

Vite配置：

// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/xxx时，开发服务器把请求转发到后端8080端口。这里有一个容易踩的坑：代理的/api前缀和后端接口的context-path要对应好。如果后端接口本身就写成/api/order/list，那代理直接透传；如果后端接口是/order/list，前端请求写成/api/order/list，代理时要配rewrite去掉/api前缀，否则会404。

6.3 图片上传的物理路径：开发环境能用，Linux部署就丢

本地开发的时候图片上传到项目相对路径./uploads，一切正常。一部署到Linux服务器，可能因为部署目录权限、临时目录清理等原因，图片莫名其妙就访问不到了。

正确的做法是：图片上传到服务器上一个独立的物理路径（比如/data/repair/uploads），通过Nginx把这个路径映射成一个静态访问URL：

location /uploads/ { alias /data/repair/uploads/; }

后端接口返回的图片URL只存相对路径/uploads/xxx.jpg，前端拼上服务器域名就能访问。这样以后扩容或者迁移，只改Nginx配置，不动数据库。

6.4 并发更新工单状态：没有乐观锁就等着出bug

这个坑前面提过，但值得单独再强调一次。维修工A和维修工B同时看到一个待接单工单，同时点击接单，如果没有状态条件的UPDATE保护，就可能出现两个人都是"维修中"的脏数据，后端工单的worker_id来回被覆盖。

我用的方案是SQL条件更新：

UPDATE repair_order SET worker_id = #{workerId}, status = 2 WHERE id = #{orderId} AND status = 1

执行后返回影响行数，如果为0说明状态已被别人改过，直接抛"工单已被其他师傅接走"。这类问题不是理论问题，是小并发下确实会出现的。

7. 项目打包部署与后续扩展的三个思路

系统开发完不是终点，能跑、能部署、能演示才是完整交付。部署方式我给两种：

7.1 前后端分离部署：后端jar + 前端静态文件

前端项目执行npm run build生成dist目录，里面是纯静态文件。部署时有两种选择：

一是用Nginx托管前端静态文件，同时反向代理后端接口：

server { listen 80; server_name your-domain.com; location / { root /data/repair/dist; index index.html; try_files $uri $uri/ /index.html; # 解决Vue路由history模式刷新404 } location /api/ { proxy_pass http://localhost:8080/; } }

二是直接把dist目录拷进SpringBoot项目的src/main/resources/static下，重新打包成一个jar，单端口部署。这种方式适合毕设演示，一台服务器、一个进程就能跑完整个系统。我自己的习惯是推荐Nginx方式，更贴近生产环境，也方便日后前端独立升级。

7.2 部署之后的基础体检清单

系统上线前，我在项目里统一做了这几项检查，建议你也照着过一遍：

• 数据库密码：不要用root/root这种弱口令，至少改成大小写字母+数字混合。
• 接口鉴权：登录、工单操作等敏感接口逐一验证未登录/越权访问是否被拦截。
• 前端404处理：Vue路由如果是history模式，Nginx必须配try_files，否则刷新页面白屏。
• 日志输出：SpringBoot配置logback-spring.xml，把错误日志输出到独立文件，排查问题不靠看控制台。

7.3 这套系统的三个扩展方向

最后说点进阶的。宿舍维修管理系统做完主干，想让它更值钱，可以往这三个方向延伸：

第一，微信小程序端。学生报修的主场景在手机，PC端报修始终不方便。小程序端复用后端现有接口，只需要新写一套前端，业务逻辑改动用蓝牙打印小票、扫码报修等场景都能加。

第二，消息通知。目前工单状态变了，学生和师傅都是被动刷新页面才知道。可以引入WebSocket，工单派发时实时推送消息给维修工，完工时实时推送给学生，体验会上一个台阶。后端用Spring的WebSocketHandler，前端用原生WebSocket，对接入不算难。

第三，数据大屏。后勤处领导要看的不是操作界面，是数据大屏——工单量趋势、维修耗时榜、学生满意度指数，用ECharts拼一个大屏页面，投到后勤办公室的显示器上，那效果对我们做系统的来说，比任何PPT答辩都好使。

这套系统的开发思路和核心代码逻辑到这里已经全部讲透了。从需求拆解到表设计，从后端状态机到前端权限路由，再到部署排坑，每一步都是从实际开发中沉淀出来的。其中最核心的认知我想再强调一次：把业务状态流转想清楚，比堆任何技术都重要。状态机定好了，后面的表结构、接口设计、前端按钮显隐全都能顺理成章地长出来。做管理系统，真正的难点从来不是框架，而是对业务的理解和取舍。祝各位都能用这套思路，交出一份漂亮的实战项目。