烂人不配爱1. 项目背景与需求分析
高校计算机实验室作为教学科研的重要场所，设备数量庞大且使用频率高。传统报修方式存在几个典型痛点：纸质登记易丢失、维修进度不透明、数据统计困难。我曾参与过某高校计算机中心的运维工作，亲眼见过值班室里堆积如山的报修单和Excel表格里互相矛盾的维修记录。
基于Python的Web报修系统能有效解决这些问题。Django和Flask作为Python两大主流Web框架各有优势：Django自带完善的后台管理，适合快速构建数据密集型应用；Flask则更轻量灵活，适合API开发。微信小程序作为前端入口，比网页版更符合学生使用习惯——不用记网址，扫码即用。
这个系统需要实现的核心功能包括：
- 用户角色管理（学生、维修员、管理员）
- 故障分类与优先级设置
- 工单状态追踪（待处理/维修中/已完成）
- 维修评价与反馈
- 数据可视化报表
实际开发中发现：高校场景的特殊性在于学期初设备故障集中爆发，系统必须能承受瞬时高并发请求。某次开学第一周单日最高收到327条报修申请，这对数据库设计提出了挑战。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与架构设计
2.1 框架组合方案
采用Django+Flask混合架构并非标新立异，而是基于实际需求：
- 用Django的ORM管理核心数据模型（用户、设备、工单）
- 用Flask构建RESTful API接口（小程序通信专用）
- 两者共享同一个MySQL数据库
这种架构的优势在于：
python复制# Django模型示例（lab_management/models.py）
class RepairOrder(models.Model):
PRIORITY_CHOICES = [
(1, '紧急'),
(2, '高'),
(3, '普通')
]
device = models.ForeignKey('Device', on_delete=models.CASCADE)
reporter = models.ForeignKey(User, related_name='reported_orders')
technician = models.ForeignKey(User, related_name='assigned_orders', null=True)
description = models.TextField()
status = models.CharField(max_length=20, default='pending')
created_at = models.DateTimeField(auto_now_add=True)
def get_absolute_url(self):
return reverse('order-detail', kwargs={'pk': self.pk})
2.2 小程序端关键技术
微信小程序开发需特别注意：
- 导航栏高度适配：获取胶囊按钮位置信息
javascript复制const menuInfo = wx.getMenuButtonBoundingClientRect()
this.setData({
navHeight: menuInfo.bottom + 10
})
- 文件上传处理：需配置合法域名且不超过10MB
- 登录流程：通过wx.login获取code，后端用code2session接口换取openid
2.3 部署方案对比
测试环境推荐：
- 开发机：Python 3.8+ + SQLite
- 联调环境：Docker容器化部署
生产环境建议：
bash复制# 宝塔面板部署示例
pip install -r requirements.txt
python manage.py collectstatic
python manage.py migrate
gunicorn -w 4 -b 0.0.0.0:8000 lab_management.wsgi:application
3. 核心功能实现细节
3.1 工单生命周期管理
状态机设计是报修系统的核心逻辑：
code复制待分配 → 已分配 → 维修中 → 待验收 → 已完成
↑ ↓
└── 需返修 ←─┘
对应的Django视图处理：
python复制@login_required
def update_order_status(request, order_id):
order = get_object_or_404(RepairOrder, pk=order_id)
new_status = request.POST.get('status')
# 状态转换校验
valid_transitions = {
'pending': ['assigned'],
'assigned': ['in_progress', 'pending'],
'in_progress': ['pending_approval'],
'pending_approval': ['completed', 'needs_rework'],
'needs_rework': ['in_progress']
}
if new_status in valid_transitions.get(order.status, []):
order.status = new_status
order.save()
return JsonResponse({'success': True})
return JsonResponse({'error': '非法状态转换'}, status=400)
3.2 实时通知机制
采用WebSocket实现状态变更推送：
- Django Channels配置
python复制# routing.py
from channels.routing import ProtocolTypeRouter
application = ProtocolTypeRouter({
"websocket": AuthMiddlewareStack(
URLRouter([
path("ws/notifications/", NotificationConsumer),
])
),
})
- 前端小程序监听
javascript复制const socket = wx.connectSocket({
url: 'wss://yourdomain.com/ws/notifications/',
success: () => console.log('连接建立')
})
socket.onMessage((res) => {
const data = JSON.parse(res.data)
if (data.type === 'STATUS_UPDATE') {
this.updateOrderStatus(data.orderId, data.newStatus)
}
})
4. 性能优化与安全实践
4.1 高并发应对策略
针对开学季的流量高峰，我们采取了以下措施：
- 数据库读写分离：配置MySQL主从复制
- 缓存热点数据：
python复制from django.core.cache import cache
def get_device_stats():
key = 'device_stats'
result = cache.get(key)
if not result:
result = Device.objects.aggregate(
total=Count('id'),
broken=Count(Case(When(status='broken', then=1)))
)
cache.set(key, result, timeout=3600)
return result
- 异步任务处理：Celery处理报表生成等耗时操作
4.2 安全防护要点
高校系统尤其需要注意：
- 权限控制：Django guardian实现对象级权限
python复制@permission_required('lab.change_repairorder')
def edit_order(request, order_id):
...
- 防XSS：小程序端自动转义HTML，Django模板使用
|safe过滤器要谨慎 - 数据脱敏：学号等敏感信息在前端显示时应做掩码处理
5. 实际部署中的经验教训
在三个高校的落地实施过程中，我们总结了这些关键经验：
- 字段设计要预留扩展空间
- 最初设计的设备表缺少"购置年份"字段，导致无法统计设备老化情况
- 解决方案：使用JSONField存储动态属性
- 微信小程序审核注意事项
- 隐私协议必须明确说明收集哪些数据
- 用户手机号收集需要单独申请权限
- 报修内容需设置敏感词过滤
- 性能监控方案
python复制# prometheus_client自定义指标
REQUESTS_IN_PROGRESS = Gauge(
'django_requests_in_progress',
'当前处理中的请求数',
['method', 'endpoint']
)
@method_decorator(lambda f: REQUESTS_IN_PROGRESS.labels('GET', 'order-list').track_inprogress())(OrderListView.get)
- 异常处理要友好
- 数据库连接失败时提供离线模式
- 小程序端缓存未提交的报修单
javascript复制wx.setStorageSync('draft_orders', orders)
这套系统在某高校运行一年后，设备报修响应时间从平均3.2天缩短到0.5天，学生满意度提升47%。最关键的是建立了完整的设备健康档案，为后续的采购决策提供了数据支持。