Python Flask实现的高校教室报修管理平台：工单流转与资源台账全解析

教室报修这个事，看起来小，做起来头疼。我接到这个需求时的背景是这样的：高校教学楼几十间教室，设备坏了靠口头通知、纸质登记，维修师傅跑上跑下，管理员坐在办公室里根本不知道哪个教室还没修、修到哪一步了。于是就有了这个基于 Python Flask 的高校教室报修资源管理平台。它要解决的不只是“报修登记”，而是把教室资源、设备台账、报修工单、维修人员调度串成一条完整链路，让每一次报修都有迹可循、让管理员的统计从“翻本子”变成“看页面”。

这篇文章我会把整个项目从需求拆解、技术选型、模块实现到部署上线的过程完整复盘一遍，重点讲清楚每个设计决策背后的原因和踩过的坑，适合正在做课程设计、毕业设计，或者想拿 Flask 练一个完整业务系统的同学参考。项目本身不复杂，但麻雀虽小五脏俱全：三种角色权限、资源管理、工单流转、统计看板，这些逻辑搞明白后，换到任何管理类系统都能套用。

1. 项目概述与需求拆解

1.1 报修管理的现实痛点

高校教室报修这个场景，最典型的状态是这样的：一门课上到一半投影仪突然坏了，学生代表跑去找楼下管理员，管理员拿出一个皱巴巴的本子记下来，然后打电话联系维修师傅。维修师傅根据本子上的信息挨个教室跑，结果有的教室已经临时换课没人来，有的设备其实只是没通电，真正需要维修的反而被排在后面。

我接手项目后先去蹲点了两所学校的教室管理员办公室，蹲完的感受是：问题不在“没人报修”，而在“报修信息失真的链路太长”。纸质登记的信息缺失率非常高，故障描述写成“投影坏了”四个字，根本不包含教室编号、设备型号、报修时间、紧急程度。等维修师傅看到本子，时间已经过去半天，信息还要靠猜。

平台要解决的核心痛点可以拆成三条：第一条是信息结构化，报修必须关联具体教室、具体设备、具体故障现象；第二条是流程可追踪，每一张报修单从提交到处理完毕的每一步操作都要有记录；第三条是管理可统计，管理员期末写设备维护报告时，能从系统直接拉出每个月报修次数、故障设备排名、平均维修时长这些数据。

1.2 角色设计与业务流程梳理

我把系统按使用角色划分成三类，每一个角色只做自己职责范围内的事情，避免权限交叉导致混乱。

报修单的生命周期我最终定义为“五状态循环”：待审核 → 已派单 → 维修中 → 已完成 → 已评价。每个状态变化的动作都很明确：用户在首页填表提交，系统进入“待审核”；管理员看到新报修后指定维修工，状态改为“已派单”；维修工点击开始维修变为“维修中”；维修工提交处理结果后变为“已完成”，此时用户端可以填写评价，变为“已评价”。

这里有一个容易被忽略的设计重点：状态流转不能允许倒退。比如维修中之后不能直接跳回待审核，否则维修工误操作会把整个流程搞乱。我在代码里是通过一个状态映射表来约束合法迁移路径，这是一个在答辩时会被频繁追问的设计点，提前想清楚会加分。

1.3 功能边界控制

我见过很多同类项目失败，不是因为功能太少，而是因为功能太多。有人一上来就想加在线支付、短信通知、地图定位，结果开发量翻了数倍，核心流程反而没跑通。

这次我给自己定的原则是：把“报修闭环”做透，其他一律排到二期。所以第一版砍掉了以下功能：自动排班、维修评价打分权重、消息推送、微信小程序端。只保留一个看板页面的简单统计，因为管理员确实需要快速看到“今天还有几单没处理”。

砍功能不等于不做接口预留。我在数据库设计时为用户表预留了一份 role 字段，为后续接入企业微信通知留了一个 message_push 扩展位，这样二期接入时不需要改动表结构。

2. 技术选型与整体架构设计

2.1 为什么是 Flask 而不是 Django

选 Flask 不选 Django，很多人第一反应是“Django 更重更全”。这个说法对，但不完全。对于这个项目，核心决策因素有三个：第一，系统规模属于校园级，用户同时在线量不大，并发峰值可能不超过几十个人，Flask 这种轻量框架完全够用，不需要 Django 自带的重型 ORM 和 Admin 后台；第二，Flask 的 Jinja2 模板和原生路由写法非常直观，即使初学者也能快速理解请求是怎么进来的、页面是怎么渲染出去的，这对后续维护和课程设计展示都很友好；第三，Flask 的第三方扩展生态虽然是“按需选装”，但最基本的 flask-sqlalchemy、flask-wtf、flask-login 都有成熟稳定的版本，组合起来并不比 Django 缺东西。

Flask 被质疑最多的一点是“没有固定的项目结构”，但从另一个角度看，这也意味着我可以根据项目实际规模去定制目录。后面会详细讲我采用的蓝图结构，它在表达能力上完全够用。

2.2 数据库选型与表关系设计

数据库我在开发阶段使用 SQLite，部署到生产环境换成 MySQL。原因比较现实：SQLite 零配置、单文件、方便本地调试，适合初期把业务逻辑跑通；但它对并发写入支持较弱，校园正式使用中会出现多个维修工同时更新工单的情况，所以生产环境必须换 MySQL。

表结构我设计了五张核心表：用户表、教室表、设备表、报修单表、操作日志表。先看最简单的三张基础表。

用户表字段：id、username、password_hash、real_name、role（user/worker/admin）、phone、created_at。密码绝不存明文，用 werkzeug.security 提供的 generate_password_hash 加密。

教室表字段：id、name（如“教学楼A-301”）、building（所属楼宇）、floor（楼层）、capacity（座位数）、status（可用/停用/维修中）。

设备表字段：id、classroom_id（外键关联教室）、equipment_type（投影仪/电脑/音响/空调）、model（型号）、asset_no（资产编号）、purchase_date（采购日期）、status。

报修单表是整个业务的核心，字段较多，下面单列说明。

报修单表字段：id、repair_no（工单号，年月日+序列号）、user_id（报修人）、classroom_id、equipment_id（可空，因为有时是整个教室灯管坏了）、fault_desc（故障描述）、fault_type（故障分类）、priority（紧急程度）、status（五状态之一）、assigned_worker_id（派单维修工）、admin_id（审核人）、created_at、updated_at、solved_at（完成时间）、feedback（用户评价）。

操作日志表用来记录每一次状态变更的详情：id、repair_id、operator_id、action（提交/审核/派单/开始维修/完成/评价）、remark、operated_at。

这五张表的关系用一句话概括：用户表公告报修单，教室表关联设备表，报修单挂在教室和设备之下并绑定操作全过程。在用 SQLAlchemy 定义模型时，外键关系不要偷懒只写字段不写 relationship，后续做前端联动筛选会非常麻烦。

2.3 项目目录结构与蓝图划分

Flask 项目最忌讳把所有路由写在一个 app.py 里。我见过太多初学者最后改一个功能要滚动半天找函数，这次我按业务域拆成三个蓝图，目录结构如下：

repair-platform/ ├── run.py # 启动入口 ├── config.py # 配置分离 ├── requirements.txt # 依赖清单 ├── app/ │ ├── __init__.py # 应用工厂 │ ├── models.py # 所有数据模型 │ ├── forms.py # 表单校验 │ ├── auth/ # 登录注册蓝图 │ ├── resource/ # 教室/设备管理蓝图 │ ├── repair/ # 报修核心流程蓝图 │ ├── dashboard/ # 统计看板蓝图 ├── templates/ │ ├── base.html # 公共模板 │ ├── auth/ # 登录注册页面 │ ├── resource/ # 资源管理页面 │ ├── repair/ # 报修相关页面 │ └── dashboard/ # 统计页面 └── static/ ├── css/ ├── js/ └── uploads/ # 上传图片目录（若有）

启动方式用应用工厂模式：在app/__init__.py中创建 app 实例并注册蓝图，run.py只负责读取配置并调用工厂方法。这样做的好处是测试时可以直接 import app 而不会重复初始化。

3. 核心功能实现详解

3.1 登录与会话权限控制

权限控制是整个系统安全的基础。我用 Flask 的 session 配合装饰器实现，没有引入重量级的 flask-login，因为本项目角色逻辑简单，自实现反而更好理解。

核心代码如下：

from functools import wraps from flask import session, redirect, url_for, flash def login_required(f): @wraps(f) def wrapper(*args, **kwargs): if 'user_id' not in session: flash('请先登录后再操作', 'warning') return redirect(url_for('auth.login')) return f(*args, **kwargs) return wrapper def role_required(*roles): def decorator(f): @wraps(f) def wrapper(*args, **kwargs): if 'user_id' not in session: return redirect(url_for('auth.login')) if session.get('role') not in roles: flash('没有权限执行此操作', 'danger') return redirect(url_for('main.index')) return f(*args, **kwargs) return wrapper return decorator

使用方式很直接：维修工接口加@role_required('worker', 'admin')，管理员接口只用@role_required('admin')。这里有个我踩过的坑：Flask 的 session 默认通过 cookie 存储，SECRET_KEY如果不配置，每次重启服务后 session 都会失效，用户必须重新登录。所以 config.py 里一定要写一个固定的、足够随机的 SECRET_KEY。

装饰器的顺序也值得注意：如果多个装饰器叠加，@login_required必须放在外层、路由装饰器@app.route放在最外层，否则路由判断先于登录判断执行，未登录用户会被放行到视图函数内部才被拦截，虽然逻辑上还是能拦下来，但 URL 行为会变得很怪。

3.2 教室资源台账管理

教室资源模块本质上是一个基础数据维护页面。管理员登录后可以新建教室、停用教室、添加设备、修改资产的归属状态。这块功能从实现难度上看不复杂，但它是报修流程的“数据地基”。

我花了比较大的心思在页面联动上。提交报修表单时，用户先选教学楼，再选楼层的教室列表，最后根据该教室下的设备列表选择故障设备。这三级联动如果不用 Ajax，每次刷新页面都会丢失已选状态，体验很差。我的方案是三个独立接口返回 JSON：

@app.route('/api/classrooms_by_building/<building>') def classrooms_by_building(building): rooms = Classroom.query.filter_by(building=building, status='active').all() return jsonify([{"id": r.id, "name": r.name} for r in rooms])

前端用 jQuery 的$.getJSON监听下拉框 change 事件，依次填充下一级列表。这里有一个细节：设备列表可能出现“全部设备已正常”的情况，所以下拉框的第一项永远是“不指定具体设备”，对应数据库里 equipment_id 为 NULL，用于整间教室的维修场景。

设备状态在报修完成后应该被自动联动更新。比如一台投影仪报修完成且标记为“已更换灯泡”，它的状态应该从“故障”变为“可用”。这个我是在报修单完成的时候额外做了一次equipment.status = 'active'的更新，而不是让管理员手动再去设备管理页改，减少了一个容易遗漏的人工环节。

3.3 报修工单核心流转

报修流程是整个平台的重头戏，我把它拆成了五个子场景：创建工单、审核派单、维修处理、完成反馈、状态时间线。

创建工单的视图接收前端表单 POST 数据，先做基础校验，比如故障描述不能为空、选定的教室必须存在。校验通过后生成工单号，格式是BX + 年月日 + 三位序号，例如BX20250112001。生成逻辑很简单：查当天最大序号加一，避免并发时重号最简单的方式是在序号字段上建唯一索引，如果插入报唯一冲突就重试一次。

审核派单是管理员的专属操作界面。页面上默认只显示待审核列表，每条报修单旁边有一个“派单”按钮，点击后弹出一个维修工下拉选择框。核心视图如下：

@repair_bp.route('/repair/<int:repair_id>/assign', methods=['POST']) @role_required('admin') def assign_repair(repair_id): repair = RepairOrder.query.get_or_404(repair_id) worker_id = request.form.get('worker_id', type=int) worker = User.query.get(worker_id) if not worker or worker.role != 'worker': flash('请选择有效的维修人员', 'danger') return redirect(url_for('repair.repair_detail', repair_id=repair_id)) repair.assigned_worker_id = worker_id repair.status = 'assigned' repair.admin_id = session['user_id'] db.session.commit() flash('派单成功', 'success') return redirect(url_for('repair.repair_detail', repair_id=repair.id))

维修工登录后看到的是“我的工单”列表，分为待处理和已处理两组。点击开始维修调用一个接口更新状态为 processing，点击完成则需要填写处理结果字段，并选择该设备是否恢复正常。两个动作分别对应状态机里的合法迁移，不允许跨状态操作。

用户在个人中心可以看到自己的历史工单和当前进度，状态为已完成时可以提交反馈，填写的内容写入 feedback 字段，同时状态变为 evaluated。

为了让整个工单流转的每一步都清晰可见，操作日志表在每一个动作发生时都会插入一条记录，渲染到详情页的底部时间线上。这个设计在答辩时是亮点，因为“能证明系统流程完整”比“功能能跑”更有说服力。

3.4 统计看板模块

统计看板是给管理员做“滚动管控”用的，不需要做得多花哨，关键是数据准确和刷新及时。

我实现了四个核心指标：待处理工单总数、本月新增报修数、平均维修完成时长、故障设备排行 Top 5。前两项直接用 SQLAlchemy 的 count 和 created_at 时间过滤实现；平均维修时长则是查询所有已完成工单中solved_at - created_at的平均值。故障设备排行需要 group by equipment_id 然后按 count 倒序，注意 equipment 为空（整间教室报修）的数据要过滤掉。

图表展示我没有用 ECharts 而是用最简单的纯 CSS 表格水平条，因为这类校内系统用户只关心数字，不关心炫酷交互。图表库往往要引入大体积的 JS 文件，在校园网环境下加载速度反而更慢，得不偿失。

4. 实操过程与关键代码

4.1 环境准备与项目初始化

从零开始复现这个项目，第一步是确认环境。我的建议是 Python 3.10 及以上版本，不要用 3.6 以下的老版本，因为很多 Flask 扩展已经不再兼容旧版语法。

安装依赖用 pip，一行命令搞定：

pip install flask flask-sqlalchemy flask-wtf python-dotenv

这里额外说一句，flask-wtf 不是只用来做表单验证的。它的 CSRF 保护功能非常关键，默认每个 POST 表单都需要带{% csrf_token() %}才能通过校验，能有效防止跨站请求伪造。如果不喜欢写模板标签，也可以通过app.config['WTF_CSRF_ENABLED'] = False全局关闭，但我不建议在生产环境这么干。

创建虚拟环境是必须的操作，不要图省事直接装在系统 Python 全局环境里面。不同项目依赖版本互相污染的问题，等你要部署第二个 Flask 项目时就会深刻体会到。推荐 python -m venv 创建虚拟环境，具体命令如下：

python -m venv venv source venv/bin/activate # Linux/macOS venv\Scripts\activate # Windows

4.2 数据模型定义与建库

数据模型我用 Flask-SQLAlchemy 定义，以设备表和报修单表为例，实际代码可以这样写：

from flask_sqlalchemy import SQLAlchemy from datetime import datetime db = SQLAlchemy() class Equipment(db.Model): __tablename__ = 'equipment' id = db.Column(db.Integer, primary_key=True) classroom_id = db.Column(db.Integer, db.ForeignKey('classroom.id'), nullable=False) equipment_type = db.Column(db.String(32), nullable=False) model = db.Column(db.String(64)) asset_no = db.Column(db.String(64), unique=True) status = db.Column(db.String(16), default='active') # active/breakdown/inactive created_at = db.Column(db.DateTime, default=datetime.now) classroom = db.relationship('Classroom', backref=db.backref('equipments', lazy='dynamic')) class RepairOrder(db.Model): __tablename__ = 'repair_order' id = db.Column(db.Integer, primary_key=True) repair_no = db.Column(db.String(32), unique=True, nullable=False, index=True) user_id = db.Column(db.Integer, db.ForeignKey('user.id'), nullable=False) classroom_id = db.Column(db.Integer, db.ForeignKey('classroom.id'), nullable=False) equipment_id = db.Column(db.Integer, db.ForeignKey('equipment.id'), nullable=True) fault_desc = db.Column(db.Text, nullable=False) fault_type = db.Column(db.String(16)) priority = db.Column(db.String(8), default='normal') # low/normal/urgent status = db.Column(db.String(16), default='pending') assigned_worker_id = db.Column(db.Integer, db.ForeignKey('user.id'), nullable=True) admin_id = db.Column(db.Integer, db.ForeignKey('user.id'), nullable=True) created_at = db.Column(db.DateTime, default=datetime.now) updated_at = db.Column(db.DateTime, default=datetime.now, onupdate=datetime.now) solved_at = db.Column(db.DateTime, nullable=True) feedback = db.Column(db.Text, nullable=True) reporter = db.relationship('User', foreign_keys=[user_id], backref='reported_repairs') worker = db.relationship('User', foreign_keys=[assigned_worker_id]) classroom = db.relationship('Classroom') equipment = db.relationship('Equipment')

定义好模型后，初始化库表的操作是在命令行执行：

from app import db, create_app app = create_app() with app.app_context(): db.create_all()

create_all()只负责创建缺失的表，不会更新已有的表结构。开发阶段如果改了模型字段，最直接的方式是删掉数据库文件重新创建，或者用 Flask-Migrate 做正规迁移。如果后面要长期维护，建议从第一天就接上 Flask-Migrate，否则表结构改到第三次时你会后悔。

4.3 表单校验与信息发布

用户提交报修是最需要做数据校验的环节。我没有手写一堆 if 判断，而是用 flask-wtf 的 FlaskForm 声明式写法：

from flask_wtf import FlaskForm from wtforms import StringField, TextAreaField, SelectField, IntegerField from wtforms.validators import DataRequired, Length class RepairForm(FlaskForm): classroom_id = SelectField('所在教室', coerce=int, validators=[DataRequired()]) equipment_id = SelectField('故障设备', coerce=int, validators=[DataOptional()]) fault_type = SelectField('故障分类', choices=[('projector', '投影仪问题'), ('network', '网络故障'), ('power', '供电问题'), ('other', '其他')], validators=[DataRequired()]) fault_desc = TextAreaField('故障描述', validators=[DataRequired(), Length(max=500)]) priority = SelectField('紧急程度', choices=[('low', '一般'), ('normal', '中等'), ('urgent', '紧急')], default='normal')

wtforms 的组件会自动渲染 HTML 并进行字段类型转义。SelectField 用coerce=int可以把表单提交的字符串转换为 int，如果转换失败直接抛校验错误，不需要手动处理 ValueError。

发布报修后的信息回显也很重要。用户提交成功后页面不会跳转到列表而是留在详情页，并把用户刚才填的描述原样显示在故障描述区，这样用户可以自己检查有没有写错。这个体验细节是蹲点的时候观察出来的——很多用户根本不知道自己提交的描述在管理员那边是什么样子。

4.4 模板页面搭建与前端联动

Jinja2 模板是 Flask 的原生渲染方式。base.html 里我统一做了三部分：顶部导航栏、左侧菜单（根据角色显示不同菜单项）、中间内容区。所有子页面只需要继承 base 并覆盖 content block。

以报修列表的模板片段为例：

{% extends "base.html" %} {% block content %} <div class="card"> <div class="card-header"> 我的报修记录 <a href="{{ url_for('repair.create') }}" class="btn btn-primary btn-sm float-end">新建报修</a> </div> <table class="table table-striped"> <thead> <tr> <th>工单号</th> <th>教室</th> <th>设备</th> <th>状态</th> <th>提交时间</th> <th>操作</th> </tr> </thead> <tbody> {% for repair in repairs.items %} <tr> <td>{{ repair.repair_no }}</td> <td>{{ repair.classroom.name }}</td> <td>{{ repair.equipment.equipment_type if repair.equipment else '整间教室' }}</td> <td>{{ status_map[repair.status] }}</td> <td>{{ repair.created_at.strftime('%Y-%m-%d %H:%M') }}</td> <td><a href="{{ url_for('repair.detail', repair_id=repair.id) }}">查看</a></td> </tr> {% endfor %} </tbody> </table> </div> {% endblock %}

前端联动之前提过的下拉框三级筛选，这里用到一个小技巧：页面加载时先获取教学楼列表，教师选择变化后触发 ajax 请求对应楼层与教室，而不是一次性把全部数据塞进一个下拉框。原因是教室多的学校有上百间，全量加载不仅慢，用户找起来也费劲。

状态显示我维护了一个 Python 字典映射：

status_map = { 'pending': '待审核', 'assigned': '已派单', 'processing': '维修中', 'completed': '已完成', 'evaluated': '已评价' }

模板里直接用status_map[repair.status]，显示中文，数据库里存英文枚举值。这个映射表的好处是扩展新状态只需要改一处，比如以后加“驳回”状态，只需要在映射里加一行。

4.5 本地运行与冒烟测试

所有代码写完后的第一轮自测，我按照真实业务流程从头到尾走了一遍：管理员登录并创建教室和设备 → 普通用户注册并提交报修 → 管理员审核并派单 → 维修工接单并更新进度 → 用户评价反馈。

启动开发服务器的命令很简单：

python run.py

默认访问http://127.0.0.1:5000。这里要提醒一点：Flask 自带的开发服务器app.run(debug=True)只适合本地调试，一定不要直接拿它做正式服务。开发模式下 debug 为 True 时会开启交互式调试器，任何访问者都可能拿到 Python 执行环境，这是极大的安全隐患。

冒烟测试阶段我发现了一个很有代表性的事情：用户提交报修时选择“整个教室”而不指定设备，但在教师列表页做筛选查询时，用了 INNER JOIN 把没有设备的报修单全部过滤掉了。这就是典型的 join 使用场景错误，应该用 LEFT OUTER JOIN 保留报修表的所有记录，设备信息为空时显示“整间教室”。这个 bug 让我明白，写查询时先想清楚“主表是哪张、要不要保留无匹配行”，再动笔写 join。

5. 常见问题与排查实录

5.1 问题速查表

开发过程中我记录了不少典型报错，整理成速查表，很多是刚接触 Flask 的同学一定会碰到的。

这里挑几个详细展开。

5.2 SQLite 锁与并发写入

开发阶段我用 SQLite，第一次压测时发现维修工同时点了两次“开始维修”，页面直接报database is locked。原因很简单：SQLite 同一时间只允许一个写事务，两个并发请求同时写入就会冲突。

解决思路有三个层次。最轻量的是给 SQLAlchemy 连接配置一个超时参数：

SQLALCHEMY_ENGINE_OPTIONS = { 'connect_args': {'timeout': 10} }

这只解决“等待”问题，如果请求量再大还是不行；正路是生产环境换 MySQL；还有一个被很多人忽略的优化是事务保持短小，不要在事务中间去做耗时的外部请求或者渲染模板。我曾经为了省事，在同一个事务里既更新了工单状态又调用了一个外部的 Python 脚本做数据清洗，结果那个脚本运行了三秒钟，期间所有其他写请求全部排队超时。把外部调用挪出事务之后，问题立刻消失。

5.3 时间显示时区问题

很多初学者在报修单详情页看到的时间比实际时间晚了 8 小时，这是因为建表时用了datetime.utcnow，而用户在中国时区。Flask 默认以 UTC 存时间，前端显示时再转本地时间也可以，但容易处处遗漏。

我的处理方式是简单粗暴：数据库里所有时间字段统一用datetime.now()存本地时间，前端模板直接显示字符串。如果以后要部署到不同时区的服务器，再迁移到 UTC 存储也不迟，但校园系统基本不会跨时区。

5.4 文件上传路径的经典坑

如果把报修现场照片上传功能加上，一定要提前规划文件名和路径。我最开始直接使用了用户原始文件名，结果两个用户上传了同名照片，后一个覆盖了前一个。

修复方案是给文件名加 uuid 前缀：

import uuid from werkzeug.utils import secure_filename ext = filename.rsplit('.', 1)[-1].lower() new_filename = f"{uuid.uuid4().hex}.{ext}"

secure_filename会过滤掉路径和特殊字符，避免像../../etc/passwd这样危险的文件名。上传目录只保存新文件名，原始文件名存入数据库字段。另外上传目录必须放在static/uploads下，并且给目录授予可读权限，否则浏览器访问图片会 403。

5.5 开发服务器端口被占用

address already in use这个报错我也反复遇到过，尤其是跑单元测试和开发服务器来回切换的时候。排查命令：

# Linux/macOS lsof -i:5000 # Windows 管理员权限下 netstat -ano | findstr :5000

找到占用进程后按 PID 杀掉即可。如果是在容器里跑，记得端口映射暴露配置要与进程监听端口一致。这里顺带说一句，Flask 启动时如果设置app.run(host='0.0.0.0')，端口默认还是 5000，不是常见的 80，最终访问 URL 要加端口号。

6. 部署上线与后续演进

6.1 gunicorn 与 nginx 的生产部署

本地跑通只是第一步，真正上线要解决三个问题：服务进程管理、反向代理、静态文件分离。我采用 gunicorn + nginx 的组合，在 Ubuntu 云服务器上的部署步骤大致如下：

pip install gunicorn gunicorn -w 4 -b 127.0.0.1:8000 run:app

-w 4是启动 4 个 worker 进程，一个简单的估算方式是服务器 CPU 核心数乘以 2 + 1。千万记得把 worker 数设得比数据库连接池大一些，不然高并发下来回握手会把数据库拖垮。

nginx 配置要点是处理好/的 proxy_pass 和/static/的 alias：

server { listen 80; server_name repair.example.edu.cn; location /static/ { alias /data/repair-platform/static/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

再用 systemd 给 gunicorn 配一个服务托管，保证服务器重启后系统自动拉起，不需要人工登服务器敲命令。gunicorn 本身不推荐直接用 root 用户跑，新建一个专用账户比较稳妥。

6.2 数据备份与日常维护

校园系统的数据量虽然不大，但报修工单是重要的资产管理依据，备份不能省。

SQLite 阶段直接拷贝文件即可，最好定时用 cron 执行：

0 2 * * * cp /data/repair-platform/data.db /data/backup/repair_$(date +\%Y\%m\%d).db

MySQL 阶段用 mysqldump 做逻辑备份，建议每周全量备份一次，每天增量备份一次。恢复流程最好实际演练一遍，确保备份文件是完整的、可用的。我见过太多人配了备份任务但从来没试过恢复，等到真出问题时才发现备份脚本早因为密码变更失效了。

运维监控方面，最简单的方式是写一个健康检查脚本定时请求/health，返回 JSON 状态码，探测失败就触发告警。这个接口实现容易但价值极高。

6.3 可扩展方向思考

这个平台跑通之后，后续值得做的扩展方向我觉得有三个。

第一是消息通知链路的打通。现在用户登录系统后才知道维修进度，太被动。可以接入企业微信机器人或者钉钉群机器人，在报修单到达关键状态时推送一条通知，学校内部系统用群机器人比短信成本低很多，一条 webhook 就能搞定。

第二是设备二维码扫码报修。给每台设备贴上一张二维码，扫描后自动带入教室号、设备号，用户只需要填故障描述，信息准确性会大幅提高。这个功能本质上是给报修表单加一个初始参数，对后端改动很小，但对用户体验的提升立竿见影。

第三是维修耗材库存联动。维修工填写“更换灯泡”之后，系统自动从耗材库存中扣减一个灯泡，库存低于阈值时提醒管理员补货。这个模块独立性强，不影响现有表结构，只要新增一个耗材表和消耗流水表就行。

我个人在实际操作中最大的体会是：这类校园级系统，最怕的不是技术不够，而是流程没有想清楚就急着写代码。这次我花在蹲点访谈和状态设计上的时间占了总开发时间的三成，后面写代码几乎是一路顺风。另外还有个实用小技巧：开发启动后先建一个演示数据脚本，一键生成模拟的教室、设备、用户和各状态报修单，这样边开发边能看到真实效果，而不是对着空数据库发愁。等要答辩或给管理员演示的时候，这份演示数据也能直接派上用场。