企业官网建设流程全解析

高校后勤报修这块，我前前后后折腾过不少项目。最深的体会是：真正难的从来不是“修东西”本身，而是报修入口太乱、分派靠吼、进度不透明、月底统计全靠翻聊天记录。这篇文章要把我基于 Java+SSM 和 Django 落地的这套高校物业工程报修系统从头到尾拆开讲——从技术栈选择、数据库状态机设计，到两端服务怎么配合、部署调试时踩过的坑，一次性聊透。不管是拿来做毕业设计参考，还是想在校内后勤场景里真正跑起来，都希望你能从里面找到能直接抄作业的东西。

1. 高校报修场景里，真正麻烦的其实不是“修”

先说业务。校园物业报修跟居民小区报修差得很远——它要面对的不只是几百户人家，而是几万名学生加上几十栋教学楼、宿舍楼、实验楼，报修类别又杂：水管爆了、灯管黑了、门窗坏了、多媒体设备失灵、消防设施异常，每一个都得有人接单、有人跟进、有人回访。我以前见过不少高校后勤还在用这种模式：学生在宿舍楼下填纸质报修本，或者打电话到物业办公室，值班人随手记在一张纸上，再口头转达给维修师傅。运气好，师傅当天去了；运气不好，这张纸就不知道夹在哪本书里了。

这套做法的致命伤有三条：

• 无留痕。报修人、报修时间、故障描述、处理过程全靠记忆，出了问题互相扯皮。
• 难分派。维修师傅谁有空、谁在某片区，只有现场经验丰富的主管心里有数，换个人就乱了。
• 无法考核。修了多少单、平均响应多长时间、返修率多高，没有任何数据支撑，后勤处想给物业公司打分都拿不出依据。

所以高校物业工程报修系统的第一价值，不是把纸质单据变成电子单据，而是把“报修—分派—维修—验收—评价”整条链路变成可追踪、可催办、可统计的闭环。

这个闭环里至少有四类角色：

围绕这套角色模型，系统的最低功能边界至少包括：报修单管理、人员与部门管理、报修分类管理、派单/抢单、移动端入口、消息通知、维修评价、数据统计。后面所有技术设计，都是为这些业务动作服务的。

2. 为什么我把管理核心放在SSM、把请求入口放在Django

项目标题里同时出现 Java+SSM 和 Django，很多人第一反应是“这不是两套后端吗”。确实，这套项目的最终形态是两套服务配合跑，但这不是为了炫技，而是有明确的分工逻辑。

2.1 SSM与Django各自擅长什么

SSM 指 Spring + SpringMVC + MyBatis 这套经典 Java 组合。它的优势在于事务控制成熟、权限框架生态完整（Spring Security/Shiro）、复杂报表查询能力强，特别适合做规则重、状态多、并发敏感的“管理核心”。在报修系统里，工单分派、状态流转、跨表事务、月底统计这几件事，用 SSM 写心里特别踏实。

Django 的强项是开发效率高，自带 Admin 后台、ORM 和模板引擎，配合 Django REST Framework 能在很短时间内把接口层搭起来，尤其适合做移动端 H5 的请求入口、文件上传、消息通知这类偏“接口”和“交互”的活。

我的分工策略是：

• SSM 作为主服务，负责业务实体、工单流转、权限管理、统计分析；
• Django 作为接入服务，负责移动端/小程序端请求的 REST 接口、图片上传、向 SSM 服务转发业务数据；
• 两套服务通过 HTTP JSON 接口通信，部分状态同步用一张公共的消息表做异步补偿。

2.2 服务间怎么通信

最简单的做法其实是“假拆分”：两套服务连同一个数据库。Django 只负责把学生提交的报修数据写入业务表，SSM 负责读表、派单、更新状态，两边都通过数据库表解耦，通信问题直接消失。

但我实测下来，纯共用库有一定风险：两边对字段的缓存、事务隔离级别不一致时，容易出现脏读和状态覆盖。所以我的做法是：Django 侧不直接改 SSM 核心工单表，而是先写一张sync_request_log表，记录“谁在什么时间提交了哪条请求”，再由 SSM 侧定时拉取（或者接收 Django 主动推送的 JSON），把数据落进工单体系。这样就算 Django 服务暂时挂了，请求也不丢，后台一恢复就能补录。

下面是在 SSM 侧接收 Django 推送请求时，Controller 的典型写法：

@Controller @RequestMapping("/api/order") public class RepairOrderController { @Autowired private RepairOrderService repairOrderService; @ResponseBody @RequestMapping(value = "/sync", method = RequestMethod.POST) public Result syncFromDjango(@RequestBody SyncOrderDTO dto) { // 校验签名，防止外部伪造请求 if (!SignUtil.verify(dto.getAppId(), dto.getTimestamp(), dto.getSign())) { return Result.error("签名不合法"); } // 落到待校验队列，Service内部再处理事务和幂等 return repairOrderService.syncOrder(dto); } }

Django 侧对应的推送逻辑其实也简单，关键是做好重试记录：

def push_order_to_java(order, retry=3): payload = { "app_id": settings.SSM_APP_ID, "timestamp": int(time.time()), "data": order.to_dict(), "sign": make_sign(order, settings.SSM_APP_SECRET), } for i in range(retry): try: resp = requests.post(settings.SSM_API_URL + "/api/order/sync", json=payload, timeout=5) if resp.json().get("code") == 200: return True except Exception: time.sleep(2 ** i) SyncFailRecord.objects.create(order_id=order.id, payload=payload) return False

这套方案带来的实际好处是：学生的报修请求都打在 Django 上，访问峰值集中在中午和晚上，就算压力大也只会影响接入层；而工单流转、派单这种要极强一致性的动作，全部发生在 SSM 内部事务里，不担心数据错乱。

3. 数据库与状态机设计：一张报修单的完整生命周期

报修系统的核心不是页面多漂亮，而是“单子”能不能准确反映真实维修进度。我把订单状态设计成了这个模型：

3.1 核心表怎么落

我尽量避免过度设计，但有几张表是跑不掉的。一张repair_order主表记录报修单本身；一张repair_worker记录维修人员及所属班组；一张assign_log记录每一次派单/改派的痕迹；一张evaluation记录评价；一张repair_process_log记录状态变更历史。主表的设计大致是这样：

CREATE TABLE `repair_order` ( `id` INT NOT NULL AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '业务单号', `student_id` INT NOT NULL COMMENT '报修人ID', `category_id` INT NOT NULL COMMENT '报修分类ID', `title` VARCHAR(100) DEFAULT NULL, `description` TEXT COMMENT '故障描述', `images` VARCHAR(500) DEFAULT NULL COMMENT '逗号分隔的图片地址', `address` VARCHAR(255) NOT NULL COMMENT '维修地点', `priority` TINYINT DEFAULT 1 COMMENT '0低 1普通 2紧急', `status` TINYINT DEFAULT 0 COMMENT '状态码，见前表', `current_worker_id` INT DEFAULT NULL COMMENT '当前维修师傅', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_order_no` (`order_no`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关键索引就那么几个：order_no用来查单号，status用来做后台列表筛选。实测中真正要小心的是current_worker_id和status在并发场景下的组合冲突，这点我在第5节详细说。

3.2 状态流转怎么做保证

状态流转我坚持“服务层统一收口”，禁止页面直接改状态字段。Service 层提供一组方法：applyDispatch、workerGrab、startRepair、completeRepair、confirmFinish、cancel，所有更新都走事务。更新的时候除了set status = 4，还强制带 WHERE 条件status = 3，相当于乐观锁：

@Transactional public boolean confirmFinish(Integer orderId, Integer operatorId) { RepairOrder order = orderMapper.findForUpdate(orderId); if (order == null || order.getStatus() != 3) { return false; } order.setStatus(4); order.setConfirmTime(new Date()); int rows = orderMapper.updateStatusWithVersion(order); return rows > 0; // rows = 0 说明有人抢先改过状态，本次操作失败 }

updateStatusWithVersion这句 SQL 很关键：

UPDATE repair_order SET status = #{newStatus}, update_time = NOW() WHERE id = #{id} AND status = #{oldStatus}

如果影响行数为 0，就说明单据状态已经被别人改了，此时要抛出提示让前端重新加载。这个方案比单纯加 Redis 锁简单，也比锁表优雅，在毕业设计演示时还能讲出“乐观锁控制并发状态”的亮点。

3.3 派单、抢单与自动轮转

派单有几种模式：调度员指定师傅、师傅自己抢单、系统按片区自动轮转。高校宿舍报修有个特点——同一栋楼坏的东西经常性质相似，让负责该片区的师傅处理效率最高。所以我把片区字段挂在repair_worker上，自动轮转时按“片区内当前工单数最少的人优先”来派。

自动轮转的核心 SQL 大概是：

SELECT w.id, w.worker_name, (SELECT COUNT(*) FROM repair_order o WHERE o.current_worker_id = w.id AND o.status IN (1,2)) AS processing_count FROM repair_worker w WHERE w.area_id = #{areaId} AND w.status = 1 ORDER BY processing_count ASC, w.load_score ASC LIMIT 1;

这里load_score是我额外加的“负载系数”，因为有的师傅手艺好、能接复杂单，但也不能把什么单子都压给他。实际跑下来，加上这个字段后，月底各师傅的工单量方差明显变小，后勤主管也满意。

4. 从建库到跑通报修闭环的落地步骤

很多刚入手的朋友拿着源码第一步就卡住：一会报数据库连接失败，一会端口冲突，一会页面出来了但提交报修没反应。这里我按最稳妥的顺序把跑通流程捋一遍。

4.1 初始化数据库和配置

先建库，字符集必须用utf8mb4，字段里存用户输入的“地址+备注”，emoji 和生僻字才不会变问号。然后导入 SQL 脚本，一共就是前面那几张核心表加用户表、权限表、通知表。导入完成后，打开 SSM 侧的jdbc.properties：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/campus_property?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=你的密码

serverTimezone=Asia/Shanghai必须写，不然本地 MySQL 8 会和 Java 默认时区对不上，时间字段全歪掉。Django 侧就在settings.py里配 DATABASES，同样覆盖同一个库的只读账号（如果按我第2节的方案，Django 只写自己的日志表）。

4.2 SSM 侧的三层结构

SSM 项目的代码路径我习惯分成 controller、service、mapper、pojo 四层。这里最容易写乱的是 Mapper XML，尤其是多条件查询。后台报修单列表通常要按状态、分类、时间范围、关键词筛，我建议用<where>标签动态拼条件：

<select id="pageList" resultType="RepairOrder"> SELECT * FROM repair_order <where> <if test="status != null">AND status = #{status}</if> <if test="categoryId != null">AND category_id = #{categoryId}</if> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR order_no LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="startTime != null">AND create_time &gt;= #{startTime}</if> <if test="endTime != null">AND create_time &lt;= #{endTime}</if> </where> ORDER BY id DESC LIMIT #{offset}, #{pageSize} </select>

4.3 Django 侧提交报修的接口

Django 接了 DRF 之后写接口非常快。我提供一个简洁版本：

class RepairOrderCreateAPIView(APIView): permission_classes = [IsAuthenticated] def post(self, request): user = request.user data = request.data order = RepairOrder.objects.create( student=user, category_id=data.get("category_id"), title=data.get("title", ""), description=data.get("description", ""), address=data.get("address"), priority=data.get("priority", 1), status=0, order_no=self.make_order_no() ) images = request.FILES.getlist("images") for img in images: RepairImage.objects.create(order=order, image=img) # 异步推送 SSM 核心服务 async_sync_order.delay(order.id) return Response({"code": 200, "msg": "报修成功", "order_no": order.order_no})

接口写好之后，直接用 Postman 模拟一次带图片的 POST 请求，看sync_order表有没有产生记录，再看 SSM 侧有没有把工单同步进repair_order。这个联调路径通了，整条报修闭环的地基就算打好了。

5. 报修全流程里最容易翻车的几个细节

代码跑通只是开始，实际用起来有四个问题，我几乎每次都会碰到，提前说清楚能帮你省一大半调试点。

5.1 图片上传的容量和路径

学生拍照报修，手机原图动辄几 MB，如果直接存服务器，Tomcat 静态目录很快就爆了。我在 Django 侧做了三个处理：

• MAX_UPLOAD_SIZE限制单张 5MB，超了直接提示；
• 用 Pillow 压缩成 WebP 格式，宽度最大 1280 像素，质量 80，一张图基本压到 200KB 以内；
• 文件名改成 UUID，避免中文名和重复名导致路径乱。

这类细节特别适合写进调试文档，因为服务器磁盘被图片塞满这件事，不做监控的话得等网站卡死才发现。

5.2 抢单并发

宿舍楼大面积爆水管时，可能同时进来几十张报修单，多个维修师傅同时抢同一单。如果抢单逻辑是先SELECT看 status、再UPDATE改 current_worker_id，高并发下必然出现“两个人同时抢到”的脏数据。我的解法在第3节已经提过，就是在 UPDATE 的 WHERE 里带状态条件——谁先 UPDATE 成功，后面的人影响行数为 0，提示“此单已被抢”。实测这个方案在常规并发量下完全够用，不必一开始就上 Redis 分布式锁。

5.3 状态回退边界

维修工填了“已完工”，学生验收时点“驳回”，状态要回到“已派单/维修中”。但这里有个坑：流程允许从高状态回退几次？我设置的是每个单据最多驳回两次，超过两次直接进入“已驳回”，由后勤管理员介入人工重派，避免学生和师傅互相拉扯，单子永远是同一个师傅处理却一直修不好。这种规则在校内场景很有必要，因为报修体验直接影响学生对后勤的满意度。

5.4 评价统计口径

后台要看“维修师傅满意度”，我用的是好评数 / 已评价单数，而不是好评数 / 总工单数。很多初版后台直接算评价分总和 / 工单总数，结果因为大量工单没评价，所有师傅的分数都被拉低，后勤处拿这个数据给物业施压，物业当然不认。统计口径必须在设计阶段就明确，并且能一键看报表明细，否则月底开会必然扯皮。

6. 验收文档、调试文档和部署时我踩过的硬坑

项目交付时一般会带源码、LW（论文/说明文档）、调试文档和讲解录屏。很多同学花大量时间写代码，最后却栽在文档和部署上。我建议调试文档一定要包含这几个部分：环境清单、启动步骤、默认账号密码、接口调试示例、常见错误对照表。下面直接给一个常见错误对照表，照着排查能省半天：

6.1 前后端分离后的部署顺序

部署时我按这个顺序操作，几乎没有出过岔子：

1. 先启动 MySQL，确认能连上；
2. 启动 SSM 服务（后台管理端），访问登录页确认正常；
3. 启动 Django 服务（学生端接口），用管理员账号在前台发起一条测试报修；
4. 查看 SSM 后台的报修单列表，确认数据到达；
5. 在后台进行派单操作，再回学生端确认状态变化；
6. 全部跑通后，再考虑接入 nginx 做反向代理和静态文件映射。

6.2 讲解答辩时最容易问到的三个点

这套项目在毕业设计答辩里，老师大概率会问这几个问题，提前准备：

• 为什么用两套技术栈而不是只用一套？ 我的回答是“接入层与管理核心分层”，重点强调 Django 的高效接口能力与 SSM 的事务/权限控制能力互补。
• 状态并发怎么保证的？ 直接讲乐观锁更新，贴 WHERE status = 旧状态这一条 SQL。
• 如果学生端有上万人同时访问怎么办？ 这个要坦诚：当前架构面向校内场景，高峰期支撑几百并发没问题，再往上需要引入 Redis 缓存和消息队列。能讲清楚瓶颈在哪，比吹“十万并发”强一百倍。

7. 实测中的复盘和几点经验

我自己带这个项目跑了几轮之后，沉淀了几条比较实在的经验，放最后给需要的人。

第一，状态字段不要用字符串。用数字码维护成本低得多，后端加枚举注释即可。接口层可以展示成文本，但数据库里存数字。第二，每次状态变更必须留日志。我见过好多同类型的后台，工单状态变了但没人知道是谁、什么时候变的，出了问题根本查不了。这个repair_process_log表就几行代码的事，却能在关键时刻救你一次。第三，通知不要只靠站内信。学生报修之后不在意后台有没有“已收到”，在意的是微信或短信有没有通知到。所以我在 Django 侧留了第三方通知的接口位，以后接公众号模板消息或短信都很方便，前期不接也能用站内信顶着。

最后再分享一个部署上的小技巧：SSM 服务启动后，用curl http://localhost:8080/api/health这种健康检查接口确认存活，再让 Django 的定时任务每 30 秒 ping 一次。两边都活着，整个报修链路才是真的“闭环”。要是哪一天学生突然反馈报修没反应，优先去看 Django 到 SSM 的推送日志，十次里有八次是签名过期或者数据库连接池被占满这种不起眼的原因。

高校物业报修这件事，只要把“单子”管清楚、把“人”分清楚、把“流程”定清楚，技术的复杂性其实并没有想象中那么高。希望这篇拆解能让你少走几步弯路，直接把精力花在真正有挑战的地方上。