基于uniapp+PHP的机房设备故障报修小程序开发实践

我们实验室有一台服务器电源报警，微信群里的接龙报修三天后才被人翻到。这种场景在机房运维里太常见了——报修信息散落在聊天记录、电话和口口相传里，没有入口、没有单号、没有处理人、更没有闭环。后来我干脆做了一个组合方案：微信小程序 + PHP + uniapp 的机房设备故障报修平台。整套系统用 uniapp 开发微信小程序端，后端用 PHP 提供接口，MySQL 存数据，覆盖从提交报修、接单处理到完成验收的完整流程。如果你正在做课设/毕设，或者学校、小企业内部确实需要一套轻量报修工具，这篇文章应该能帮上忙。我会把需求梳理、数据表结构、后端接口逻辑、小程序端写法，以及联调阶段踩过的坑都串一遍，尽量做到你照着能自己搭起来。

1. 先想清楚需求再动手：报修平台到底要解决什么问题

1.1 我见过的机房报修混乱现场

做这个系统之前，我在几个不同场景里观察过报修流程。无论是学校机房、实验室还是小公司的设备间，报修痛点高度一致。

最典型的情况是：设备故障后，使用者在微信群里喊一句“XX机房第三排电脑开不了机”，然后就没有然后了。运气好遇到管理员刚好看到消息，回复一句“收到”，运气不好消息直接被闲聊刷过去。就算真的有人去修，整个过程也没有任何结构化记录——谁报修的、什么设备、什么故障现象、谁接单、几点到场、换了什么配件、最后怎么解决的，全是靠脑子记。等月底想统计一下哪种设备故障率最高，发现根本没有数据可查。

还有一些更隐蔽的问题：维修工到了现场才发现用户只说了“电脑坏了”，但没说是蓝屏、不开机还是网络不通，导致来回跑第二趟；两个人同时看到了报修消息，结果都去处理，或者都以为对方会处理；维修完成后没有验收环节，用户根本不知道问题到底解决了没有。

这就是我当时建这个平台的核心初衷：把“报修”从即时通讯工具里的口语化消息，变成一个有序流转的业务工单。

1.2 三种角色和对应的功能地图

想要系统不混乱，第一步是把角色拆清楚。这个报修平台我分了三种用户角色：普通报修人、维修工、管理员。

普通报修人是最多的使用者。他们要能登录小程序，选择设备并提交报修单，查看自己提交过的工单状态，在工单还没被受理时允许撤回。维修工负责处理报修。他们要能看到待受理的工单并“抢单”或者被管理员指派，处理过程中可以更新处理记录，故障解决后提交维修结果等待用户确认。管理员承担管理职责。他们维护机房和设备信息，管理维修工账号，强制指派或关闭异常工单，查看整体统计。

三种角色对应的功能，从权限上可以这样划分：

1.3 为什么是“小程序 + uniapp + PHP”，而不是别的

技术选型在当时其实没有太多纠结。

先说前端。小程序是刚需，因为机房使用者不可能为了报故障专门装一个 App，微信扫一扫或者搜一下就能用才是现实的。真正的分歧在于是直接用微信原生小程序开发，还是用 uniapp。我选择 uniapp 的核心原因是：它是 Vue 语法，组件化和状态管理更顺手，而且以后如果学校想要一个 H5 管理端或者打包成 Android 应用，同一套代码可以复用很大一部分。事实证明写起来也确实比原生 WXML 舒服不少。

后端用 PHP 更直接。这个平台的并发量不会很高，日常同时在线可能就几十个人，PHP 的架构完全足够支撑，而且部署成本极低。一台轻量服务器装上 Nginx + PHP 环境就能跑，本地调试用 phpStudy 或 XAMPP 也毫无压力。对于毕设、课设或者内部小工具来说，PHP 的学习和维护门槛也比 Java、Go 要低。

这套组合的核心逻辑是：用最少的成本把业务跑通，同时给以后扩展预留空间。

2. 数据表这样设计，工单流转才不容易乱

2.1 用户设备工单附件流转记录，五张表各司其职

报修系统的数据结构核心不是“报修”这两个字，而是“工单的状态变化”。所以我在设计表的时候，除了基础的用户表、设备表、工单表之外，还特意加了附件表和状态流转记录表。数据库名可以直接用你喜欢的项目标识，比如标题里那个 u3em23f1，也可以改成 repair_system，反正连接配置抽到一个 db.php 里，换库名只改一处。

最核心的 repair_order 工单表，字段大概是这样的：

sql复制CREATE TABLE `repair_order` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '工单号，如BX20250612001',
  `device_id` int(11) NOT NULL COMMENT '报修设备ID',
  `user_id` int(11) NOT NULL COMMENT '报修人ID，关联user表',
  `fault_desc` text NOT NULL COMMENT '故障描述',
  `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0待受理 1处理中 2待确认 3已完成 4已撤销',
  `assignee_id` int(11) DEFAULT NULL COMMENT '维修工ID，关联user表',
  `assign_time` datetime DEFAULT NULL COMMENT '接单时间',
  `finish_remark` text COMMENT '维修结果说明',
  `finish_time` datetime DEFAULT NULL COMMENT '维修完成时间',
  `create_time` datetime NOT NULL COMMENT '提交时间',
  `update_time` datetime NOT NULL COMMENT '最近更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_device` (`device_id`),
  KEY `idx_user` (`user_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意几个细节。第一，工单号不要用自增 ID 直接展示给用户，用户看到“工单号 1024”没有任何感知，我采用日期加序号的组合生成方式，比如 BX20250612001，看起来正规也方便在群里沟通。第二，status 字段我用的是数字而不是字符串，原因是数字在代码里比对方便，存数据库也更省空间。第三，assignee_id 和 user_id 都指向 user 表，但含义完全不同，一个代表“报修人”，一个代表“维修处理人”，命名上要区分清楚，避免后面联表查的时候头脑发晕。

user 表在基础字段之外，主要是通过 role 字段区分角色。简单方案可以用 role = 1 表示普通用户、role = 2 表示维修工、role = 3 表示管理员。设备表 device 要记录的字段包括设备编号、名称、型号、所在机房、IP 地址或者 SN 序列号、设备状态等。我这里把“机房”做成 device 表里的 room_name 字段，没有单独建机房表。如果机房数量少，这样确实效率最高。只有当你要做“按机房统计工单量”或者“维修工按机房分组负责”的时候，才有必要单独拆出 room 表。

额外的一张 repair_attachment 附件表很轻量，字段就是 id、order_id、file_url、create_time，用于保存用户上传的故障照片。你也