宿舍的水龙头坏了三天没人修，宿管阿姨的本子上密密麻麻记满了报修单，学生一遍遍打电话催，维修工又不知道该先去哪间……这种场景在高校里太常见了。我最近完整梳理了一套基于Nodejs + Vue的高校学生宿舍报修管理系统，从学生报修、宿管审核派单、维修工接单处理到管理员统计看板，整条链路全部打通。功能覆盖面比较广：工单流转、消息通知、图片上传、满意度评价、超时提醒、数据报表都有，而且宿管端还做了专门的派单看板。这套系统适合做课程设计、毕业设计，也适合刚接触前后端分离开发的朋友拿来做练手项目，代码结构和业务流程都能学到不少东西。
1. 为什么是Nodejs+Vue：这套方案解决什么问题
1.1 宿舍报修业务的真实痛点
先聊一个很多人忽略的问题：报修管理系统到底在管什么？表面上是“学生报个事、修理工去修”，实际跑起来完全不是这么简单。
我调研过几所高校的后勤场景，发现纸质报修模式有四个明显的坑：
- 信息丢失：学生写在纸上的描述不完整，维修工到现场发现缺零件，又要回去拿，来来回回跑好几趟。
- 响应滞后：报修单在宿管那里堆着，没人审核、没人派单，学生只能干等。
- 责任推诿：修完没有记录、没有验收，出了问题说不清楚是维修质量问题还是使用不当。
- 数据盲区：哪类故障最多、哪个楼栋报修最频繁、维修工的工作量如何，完全靠拍脑袋，后勤采购和排班没有数据支撑。
报修管理系统的核心价值，就是把这一串线下流程搬到线上，让每个环节都有记录、有提醒、有统计。而高校场景还有个特点：报修量大、时间段集中（比如开学季、雨季漏水高发期），单次请求体量小但并发次数多，这类业务用Nodejs的非阻塞I/O模型处理起来很顺手。
1.2 技术选型的思考
我见过不少人纠结后端到底用 Java SpringBoot 还是 Nodejs，这里说一下我选 Nodejs 的三个理由。
第一，前后端语言统一。前端用 Vue 写，后端也用 JavaScript 写，类型思维、命名习惯、数据结构都能保持一致，开发时不用频繁切换上下文。对于个人开发或者小团队来说，维护成本低很多。
第二，上手门槛低。相比 SpringBoot 那一套 Maven 依赖、注解扫描、XML 配置，Nodejs 的 Express 框架几十行代码就能把服务跑起来，非常适合课程设计和快速原型验证。
第三，生态适配度高。报修系统里要做的图片上传、JWT 认证、WebSocket 消息推送、Excel 导出，Nodejs 生态都有成熟的中间件，安装即用，不用自己造轮子。
当然，SpringBoot 在大型企业级应用里的事务管理、微服务治理方面依然有优势，但宿舍报修系统这种体量，用 Nodejs 属于“杀鸡用牛刀正好”。
前端框架选了Vue，主要看中它的渐进式设计。项目小的时候可以只用它的响应式和组件化能力，后面功能多了再引入 Vue Router 做路由、Pinia 做状态管理，不会一上来就把新手砸晕。
这个项目我按三种角色拆功能：学生负责发起报修和评价，宿管负责审核和派单，维修工负责接单和处理。三种角色的权限边界很清晰，后面讲权限控制的时候会专门展开。
2. 环境搭建：Nodejs、npm与Vue工程创建
2.1 Nodejs安装与环境变量配置细节
很多人在环境这一步就卡住了，尤其是 Windows 用户。我见过最多的问题就是 Nodejs 装好了，但命令行报“不是内部或外部命令”。先说标准流程。
去 Nodejs 官网下载LTS 版本，不要下载 Current 版（尝鲜版），LTS 意味着长期维护，稳定性优先。安装时一路默认即可，但有一个关键的勾选要注意：安装向导里有一项 “Add to PATH”，一定要勾上，这是把 Nodejs 加入系统环境变量的开关。如果不勾，后面 node、npm 命令全都用不了。
安装完成后，验证是否成功：
node -v npm -v如果 node -v 能输出版本号，但 npm 报错，不要慌，下一节讲的就是这个经典问题。
如果装完发现 PATH 没配上，可以手动配置。右键“此电脑” → 属性 → 高级系统设置 → 环境变量，找到 Path 这一项，把你 Nodejs 的安装目录（比如D:\Program Files\nodejs\）追加进去。这里有一点经验：追加目录时不要用相对路径，也不要带尾部的反斜杠跟分号搞混，Windows 的 Path 项之间用分号分隔，编辑框里一行一个路径。
另外建议单独建一个系统变量NODE_HOME，值为 Nodejs 安装目录，然后在 Path 里加%NODE_HOME%。这样以后升级 Nodejs，只需要改 NODE_HOME 一个地方，不需要动 Path 里的其他配置。
2.2 最常见的npm.ps1报错与解法
这个坑太经典了，搜索量常年居高不下。报错长这样：
npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。问题根源在PowerShell 的执行策略。Windows 默认执行策略是Restricted，意思是不允许运行本地 PowerShell 脚本文件，而 npm 的 .ps1 文件就是个脚本。解决思路有两种：
第一种，以管理员身份打开 PowerShell，执行：
Set-ExecutionPolicy -Scope CurrentUser RemoteSignedRemoteSigned的含义是：本地脚本可以运行，从互联网下载的脚本必须有数字签名。这是比较折中且安全的策略，改了之后重启 PowerShell，npm 命令就能正常跑了。
第二种，不想动执行策略的话，直接用CMD（命令提示符）操作 npm，CMD 不加载 PowerShell 脚本，所以没有这个问题。
这里有个小知识点：为什么 npm 要带一个 .ps1 脚本？因为 PowerShell 是 Windows 的现代终端，npm 为了让你在 PowerShell 里也能友好地调用命令，就生成了对应的 ps1 包装脚本。装完 Nodejs 之后，除了 npm.cmd 还有 npm.ps1，两者职责一致、宿主环境不同。
2.3 用Vue CLI搭建前端工程
后端服务跑起来之前，先把前端工程脚手架搭好。我用的是 Vue CLI 的方式，虽然现在 Vite 更新更快，但对于课程设计这种场景，Vue CLI 的 Webpack 体系资料多、问题排查方案成熟，不容易卡死。
npm install -g @vue/cli vue create dorm-repair-web创建过程中选择Default (Vue 3)预设，然后等依赖装完。如果下载速度慢，先把 npm 镜像切到国内源：
npm config set registry https://registry.npmmirror.com切换完之后建议顺手验证一下当前源：
npm config get registry镜像源的意义在于把下载请求指到国内 CDN，速度快且稳定。我在实际开发中遇到过 npm 装到一半报ETIMEDOUT（连接超时），十次里有八次是默认官方源不稳定导致的。
工程创建好之后，按需装核心依赖：
npm install axios vue-router@4 pinia element-plus echartsaxios：HTTP 请求库，封装所有后端接口调用。vue-router@4：前端路由控制，区分学生端、宿管端、维修工端页面。pinia：状态管理，存放用户登录信息和角色权限。element-plus：Vue 3 配套的 UI 组件库，表格、表单、弹窗、消息提示全是现成的。echarts：报表图表，宿管端的数据看板要用。
到这里，前后端的开发环境就跑通了。下面正式开始业务设计与代码实现。
3. 后端设计：从数据库到接口一步步拆解
3.1 数据库表设计与核心字段
做管理系统最重要的是先想清楚“存什么数据”，数据库结构定了，后面的接口和页面都顺了。这个系统我用 MySQL 做存储，设计了五张核心表。
用户表（users）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键，自增 |
| username | varchar(50) | 登录账号，唯一 |
| password | varchar(100) | 加密后的密码（建议 bcrypt） |
| role | tinyint | 角色：1学生，2宿管，3维修工 |
| name | varchar(50) | 真实姓名 |
| phone | varchar(20) | 手机号 |
| dorm_building | varchar(20) | 宿舍楼栋（学生填） |
| dorm_room | varchar(20) | 宿舍房间号（学生填） |
报修单表（repairs）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| user_id | int | 报修学生ID |
| title | varchar(100) | 报修标题 |
| description | text | 详细描述 |
| images | varchar(500) | 上传图片路径，多个用逗号分隔 |
| location | varchar(100) | 维修地点 |
| status | tinyint | 状态，见下一节状态机 |
| created_at | datetime | 提交时间 |
| updated_at | datetime | 更新时间 |
派单表（repair_assignments）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| repair_id | int | 报修单ID |
| worker_id | int | 维修工ID |
| assigner_id | int | 派单人（宿管）ID |
| assigned_at | datetime | 派单时间 |
| finish_time | datetime | 维修完成时间 |
评价表（repair_evaluations）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| repair_id | int | 报修单ID |
| rating | tinyint | 评分1~5星 |
| comment | varchar(255) | 评语 |
通知表（notifications）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| user_id | int | 接收人ID |
| content | varchar(255) | 通知内容 |
| is_read | tinyint | 是否已读，默认0 |
| created_at | datetime | 创建时间 |
关于密码存储，我强调一句：无论如何都不要明文存密码。很多课设项目图省事，密码直接 varchar 塞数据库，一旦数据泄露就是批量安全事故。Nodejs 里用bcryptjs包做哈希很成熟，成本低，代码也简单：
const bcrypt = require('bcryptjs'); const salt = bcrypt.genSaltSync(10); const hash = bcrypt.hashSync(password, salt);校验时用bcrypt.compareSync(明文密码, 数据库里的hash)，不需要自己维护加盐逻辑。
3.2 报修单状态机设计
报修单的状态流转是整个系统的灵魂。我用一个数字字段表示状态，避免中英文混用导致判断出错：
const REPORT_STATUS = { PENDING: 0, // 待审核：学生刚提交 APPROVED: 1, // 已通过：宿管审核完毕，等待派单 ASSIGNED: 2, // 已派单：维修工已接到任务 IN_PROGRESS: 3, // 维修中：维修工开始处理 FINISHED: 4, // 待验收：维修工填完维修结果 COMPLETED: 5, // 已完成：学生确认无误 CLOSED: 6 // 已关闭：超时未处理或取消 };状态机设计的核心价值，是避免“状态随便跳”造成的逻辑混乱。比如一张已经完成的单子不能又被派给另一个人，一个还在审核中的单子维修工不应该看到。我在后端的更新操作里都会加一个条件判断，只有当前状态符合预期才允许更新到下一状态，具体代码在 3.3 节展示。
3.3 核心接口与权限控制
后端我用 Express 写，整体结构分成三层：路由层、控制器层、数据库访问层。路由只做 URL 映射，控制器处理业务逻辑，数据库操作单独拉出来，这样代码不会全堆在一起变成“屎山”。
核心接口列表如下：
| 方法 | 路径 | 角色 | 功能 |
|---|---|---|---|
| POST | /api/auth/login | 公开 | 登录，返回 JWT |
| POST | /api/repairs | 学生 | 提交报修单 |
| GET | /api/repairs/my | 学生 | 自己提交的报修列表 |
| GET | /api/admin/repairs | 宿管 | 待审核/全部报修单 |
| PUT | /api/admin/repairs/:id/approve | 宿管 | 审核通过 |
| PUT | /api/admin/repairs/:id/assign | 宿管 | 派单给维修工 |
| GET | /api/worker/tasks | 维修工 | 我的待办任务 |
| PUT | /api/worker/tasks/:id/finish | 维修工 | 填写结果，标记待验收 |
| POST | /api/repairs/:id/evaluate | 学生 | 评价打分 |
| GET | /api/admin/stats | 宿管 | 统计报表数据 |
权限控制用 JWT 中间件实现。登录成功时签发一个 token，里面带上用户ID和角色，之后的请求都会验这个 token。
const auth = (roles = []) => (req, res, next) => { const token = req.headers.authorization?.split(' ')[1]; if (!token) return res.status(401).json({ code: 401, msg: '登录已过期' }); try { const payload = jwt.verify(token, SECRET_KEY); if (roles.length && !roles.includes(payload.role)) { return res.status(403).json({ code: 403, msg: '无权访问该接口' }); } req.user = payload; next(); } catch { res.status(401).json({ code: 401, msg: '登录状态无效' }); } }; // 宿管专属接口 app.put('/api/admin/repairs/:id/approve', auth([ROLES.ADMIN]), approveRepair);这里有个细节：为什么不直接在中间件里查一遍数据库？因为每次请求都查库会增加数据库压力，而 JWT 本身可以携带用户基本信息，验签通过就认可它。当然，如果用户被管理员封禁了，就需要在中间件里做一次状态校验，这正是不同业务的不同取舍。
派单接口是宿管端的核心操作，我加了状态条件，防止重复派单：
// 只有 APPROVED(1) 状态的单子才能派 const result = await db( 'UPDATE repairs SET status = ?, assigned_worker_id = ? WHERE id = ? AND status = ?', [REPORT_STATUS.ASSIGNED, workerId, repairId, REPORT_STATUS.APPROVED] ); if (result.affectedRows === 0) { return res.status(400).json({ code: 400, msg: '该报修单当前状态无法派单' }); }affectedRows为 0 说明更新条件不满足——这个报修单可能已经被别人处理了，或者状态已经变了。这一步就是 3.2 节说的“状态条件保护”的具体实现。
4. 宿管端功能详解：审核、派单与数据看板
4.1 报修审核与派单流程实现
宿管在这套系统里是整个流程的“调度中心”。打开宿管工作台，先看到的是一张待处理列表，用element-plus的el-table展示：报修人、宿舍楼、故障标题、提交时间、状态标签。最关键的两列操作是“通过审核”和“派单”。
审核操作调用的就是 3.3 节里的approve接口，逻辑很简单：把状态从PENDING(0)改成APPROVED(1)，同时给学生推一条站内通知，告诉他“宿管已受理，等待分配维修工”。
派单操作是我做过的最有“管理味道”的功能。宿管不是随便点个人就派的，我在派单弹窗里拉出了当前空闲维修工列表，每个维修工带着本周待处理数量。宿管优先选待处理数量少的人，实现简单的人均均衡。
派单提交之后，做三件事：
- 更新报修单状态为
ASSIGNED(2)。 - 插入一条派单记录到
repair_assignments。 - 给维修工创建一条通知“你有新的维修任务”。
我建议派单这个动作做成事务：状态更新、派单记录、通知写入，三个操作要么都成功、要么都失败。用 MySQL 事务包住，避免出现“状态改了但派单记录没插入”这种半成功的数据不一致问题。
4.2 维修进度跟踪与超时预警
派完单不代表完事，宿管最怕的是单子派下去了石沉大海。所以我在宿管端加了一个进度跟踪页，展示所有进行中的报修单，每单附上当前状态和更新时间。
这里有一个实用的功能设计：超时预警。我设了规则：派单后 4 小时内维修工没有更新状态为“维修中”，系统自动给维修工发提醒；派单后 24 小时还没有标记“待验收”，宿管那边该单会亮红标。
后端用定时任务实现，选node-cron中间件，每天整点扫一遍进行中的单子：
const cron = require('node-cron'); cron.schedule('0 * * * *', async () => { const overdue = await db( `SELECT id, assigned_worker_id FROM repairs WHERE status IN (2,3) AND updated_at < NOW() - INTERVAL 24 HOUR` ); for (const item of overdue) { await sendNotification(item.assigned_worker_id, '你有报修单已超时，请尽快处理'); } });这个功能不需要太复杂的架构，定时扫库对数据量不大的系统完全够用。如果以后报修单量涨到十几万条，可以换成消息队列延迟通知，但对高校宿舍的场景来说，定时任务就是性价比最高的方案。
4.3 宿管数据看板与统计报表
数据看板是我个人最喜欢的模块，也是“功能多”这个标签的直观体现。宿管登录后进入看板页，看到四个 KPI 卡片：今日新增报修、当前待处理、本周完成数、平均处理时长。
KPI 下面是一张按楼栋分组的柱状图，用 ECharts 渲染。后端提供统计接口，返回每个楼栋的报修总量：
app.get('/api/admin/stats/overview', auth([ROLES.ADMIN]), async (req, res) => { const today = await db( `SELECT COUNT(*) AS total FROM repairs WHERE DATE(created_at) = CURDATE()` ); const pending = await db( `SELECT COUNT(*) AS total FROM repairs WHERE status IN (0,1,2)` ); const byBuilding = await db( `SELECT location, COUNT(*) AS total FROM repairs GROUP BY location` ); res.json({ today: today[0].total, pending: pending[0].total, byBuilding }); });ECharts 在前端只需要简单传入数据和配置项，柱状饼状随便切。这套统计对后勤管理非常有用：哪个楼栋的报修频率异常高，是不是该安排专项巡检了？哪个维修工的任务积压最多，是不是该调整排班？有数据支撑，管理动作就不靠猜。
5. 前端实现：学生端与维修员端的功能落地
5.1 学生报修流程与图片上传
学生端的页面不多，核心就是“发起报修”和“查看我的报修”。发起报修的表单包含标题、详细描述、故障照片上传、楼栋房间号。这里我踩过一个典型的坑：图片上传的格式限制和大小限制。
后端我用multer接收文件，配置如下：
const upload = multer({ storage: multer.diskStorage({ destination: 'uploads/', filename: (req, file, cb) => { const ext = path.extname(file.originalname); cb(null, Date.now() + '-' + Math.round(Math.random() * 1e6) + ext); } }), limits: { fileSize: 2 * 1024 * 1024 }, // 单张2MB fileFilter: (req, file, cb) => { const allow = ['.jpg', '.jpeg', '.png', '.gif']; const ext = path.extname(file.originalname).toLowerCase(); if (allow.includes(ext)) cb(null, true); else cb(new Error('仅支持 jpg/png/gif 图片')); } });文件名的生成我特意加了时间戳和随机数，就是为了避免重名文件覆盖。原始文件名千万不要直接用，不同学生传一张404.jpg互相覆盖的情况我见过不止一次。
静态文件访问要给uploads目录开放权限，放在 Express 里：
app.use('/uploads', express.static('uploads'));这样前端拿到http://localhost:3000/uploads/xxxx.jpg就能直接预览图片。
学生查看“我的报修”时，列表按时间倒序，每条记录后面带一个状态标签：待审核、维修中、待验收、已完成等等。状态是英文数字存储的，前端需要做一次映射转换，我用一个字典搞定：
const statusMap = { 0: { text: '待审核', type: 'warning' }, 1: { text: '待派单', type: 'primary' }, 2: { text: '已派单', type: 'primary' }, 3: { text: '维修中', type: 'primary' }, 4: { text: '待验收', type: 'warning' }, 5: { text: '已完成', type: 'success' }, 6: { text: '已关闭', type: 'info' } };这里type是 Element Plus 标签的颜色类型，前端模板里直接用字典渲染，比在模板里写一堆 if/else 清爽得多。
5.2 维修员接单与回执
维修员的移动场景比较多，虽然本文没做专门的小程序端，但页面设计上采用了移动端友好的布局，宽度限制在 480px 以内，模拟“掌上工具”的体验。
维修员的待办列表展示所有ASSIGNED(2)和IN_PROGRESS(3)状态的单子。点击进入详情，能看到学生填写的完整描述和照片。维修员在详情页有两个操作按钮：
- 开始维修：把状态从已派单改成维修中，系统会记录操作时间，同时给宿管发一条通知。
- 完成维修：填写维修结果（更换了哪个零件、是否已解决），把状态改成待验收。
待验收的意义在于：维修工作完成后不能直接关闭工单，要等学生回来验收确认。这个环节保证了“修没修好”由使用者说了算，而不是维修工自己说了算，责任链路是完整的。
完成后，学生端会看到报修单状态变为“待验收”，点进去可以进行 1~5 星的评分并写评语。评价表存的就是 3.1 节里的repair_evaluations表。这个数据后面还能反哺到宿管的看板里，作为维修工绩效考核的参考。
5.3 前端路由与权限守卫
三种角色的页面用 Vue Router 管理，路由配置按角色分模块。后端接口做了权限校验，前端同样要有对应的路由守卫，不然用户直接改 URL 就能访问别人的页面，体验和安全都过不去。
const routes = [ { path: '/login', component: Login }, { path: '/student', component: StudentLayout, meta: { role: 1 }, children: [...] }, { path: '/admin', component: AdminLayout, meta: { role: 2 }, children: [...] }, { path: '/worker', component: WorkerLayout, meta: { role: 3 }, children: [...] } ]; router.beforeEach((to, from, next) => { const user = JSON.parse(localStorage.getItem('user') || '{}'); if (to.meta.role && to.meta.role !== user.role) { next('/login'); } else { next(); } });角色信息在登录成功后由后端返回，前端存到localStorage和 Pinia 里，作为页面和接口调用的通行凭证。这里有个小提醒：localStorage 存在本地，有被篡改的风险，前端做权限控制只是提升体验，真正的安全防线必须放在后端接口校验上。你前端改一下 localStorage 拦不住什么，后端 JWT 验签才能兜底。
6. 实战排雷：开发中遇到的常见问题
6.1 前后端跨域问题
前后端分离必然遇到跨域。前端跑在http://localhost:8080，后端跑在http://localhost:3000，浏览器的同源策略会把请求拦下来。
解决办法是后端引入cors中间件：
const cors = require('cors'); app.use(cors());开发阶段直接放行所有跨域请求没问题，但部署上线建议配置白名单：
app.use(cors({ origin: ['http://localhost:8080', 'https://your-domain.com'], credentials: true }));有一个易混淆的点：为什么开发阶段前端配置一个代理也能解决跨域？Vue CLI 里vue.config.js的devServer.proxy是把前端的请求转发给后端，浏览器感知不到跨域。两种方案都可行，上线之后更推荐用 Nginx 做反向代理统一入口，前后端都走同一个域名，跨域问题直接消失。
6.2 状态并发更新问题
第 3.3 节里我提到了用条件WHERE id = ? AND status = ?防重复操作。这里我展开讲讲为什么必须这么做。
假设宿管 A 和宿管 B 同时打开同一个待审核报修单，A 点“通过审核”，B 也点“通过审核”。如果代码写成：
UPDATE repairs SET status = 1 WHERE id = 5两次执行都会成功，结果没变化，看似没问题。但放在派单场景就麻烦了：两个宿管同时把单子派给不同维修工，最后派单记录只留最后一条，另一个维修工可能已经接到了任务通知，到现场才发现不是自己的单子，这就是典型的并发脏数据。
用条件更新之后：
UPDATE repairs SET status = 2, assigned_worker_id = 7 WHERE id = 5 AND status = 1第二次执行时status已经不是 1，affectedRows为 0，系统提示“该报修单已被其他人处理，请刷新”。一个简单的 SQL 条件，省去一大堆分布式锁的复杂度。
6.3 npm环境相关坑
热词列表里有大量npm.ps1报错的搜索结果，说明这个问题把很多人拦在了开发门口。除了改执行策略，我还遇到过 npm 装到一半卡死的情况，中间件下载超时、进程残留，再执行 npm install 一直报错。
我的经验是三步走：
- 确保镜像源已经切到国内源（见 2.3 节）。
- 删除
node_modules和package-lock.json，重新执行npm install。 - 如果反复失败，检查是否有杀毒软件或安全策略拦截了 npm 的临时文件写入。
另外提醒一下：Nodejs 升级不要图省事直接用安装包覆盖旧版本，容易出现 PATH 冲突和旧模块残留。建议是下载 LTS 新版本，安装时选不同的目录，然后手动改NODE_HOME指向新目录，旧版本目录删掉即可。
项目开发过程中还有一个常见的细节，Nodejs 版本跨度太大时，node_modules里的node-sass、webpack等编译型依赖容易编译失败，因为它们的原生二进制文件针对具体 Nodejs 版本编译。遇到这种问题，优先换成纯 JS 实现的替代包，比如sass替代node-sass，或者升级兼容的依赖版本。
6.4 部署经验与静态资源处理
如果只是本地跑给老师演示，npm run serve加上node server.js就够了。但要把系统真正部署到服务器，有几个点值得提前处理。
前端构建产物是静态文件，用npm run build生成 dist 目录，然后把 dist 和 uploads、server.js 一起放到服务器上，用 Nginx 托管：
server { listen 80; server_name your-domain.com; location / { root /var/www/dorm-repair/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; } location /uploads/ { alias /var/www/dorm-repair/uploads/; } }try_files ... /index.html这一行很关键。如果前端路由用了history模式（URL 里没有 #），用户直接刷新/admin/stats这种二级页面，Nginx 默认会去找对应的文件路径然后返回 404。加上这一行，所有前端路由都回落到index.html，由 Vue Router 自己解析路径。
数据库建议用 PM2 管理 Nodejs 进程，日志、崩溃自动重启都有保障。项目跑起来不是终点，稳定运行才是另一个起点的开始。
我个人在做这套系统的过程中，最深的体会是：像宿舍报修管理系统这类业务，技术上没有特别高深的地方，真正的功夫在于把流程理清楚、把边界管住。数据库表先设计好、状态机先定清楚，后面写接口和页面就是填砖头一样的事。另外，宿管端那些审核、派单、统计的细节，最好先去跟真实的宿管聊一聊，了解他们每天到底在忙什么，做出来的系统才是真正能用的——而不只是功能列表里的一行行字。
