之前帮学生会的学委搭过一套班级管理后台正好赶上期末评优那阵子班里要收作业、点名、办请假手续、还要搞匿名投票全挤在微信群里接龙信息乱成一锅粥——作业交没交要看几十条聊天记录点名要照着学号表一个个勾投票结果还得人工数票最后还差点算错。也就是从那次之后我确定了一件事大学班级管理这种场景缺的从来不是“功能”而是一个能把散落在微信群里的信息结构化收拢起来的工具。这篇内容就围绕“Python 后端 微信小程序前端”的大学班级管理系统展开核心涵盖作业、考勤、请假、投票四块业务。我会把设计思路、数据库建模、关键 API 实现和上线部署的坑完整过一遍。适合正在做课程设计或毕业设计的同学也适合想给学院做信息化改造、但不想一上来就上重型 OA 系统的学生团队参考。1. 大学班级管理的真实痛点班长和学委为什么需要一套系统先说一个很多外行人不太理解的点大学班级管理和企业办公完全是两回事。企业有行政系统、OA、钉钉但大学班级没有统一工具班长学委能用的只有微信群和 Excel。表面上功能需求只是“作业、考勤、请假、投票”实际上这四个词背后对应的是一整套零散又重复的统计工作。1.1 作业催收、格式与查重的三座大山大学的作业形式和中小学完全不一样。电子版作业要交 PDF、Word、压缩包画图类课程可能要交图片编程类课程要交代码文件。作业一多就会出现三类问题第一是提交渠道乱。有人发微信文件、有人发邮箱、有人直接发群里学委要手动把这些文件按学号归好再标记谁交了谁没交。第二是催交难。截止时间之前总有人没交学委要么群发消息要么一个个私戳碰上不回消息的还不知道是没看到还是交了忘发。第三是统计烦。到了期末老师要“平时分”学委得把交作业记录从聊天记录里重新翻出来做成表格几百条消息翻下来很容易漏。小程序解决这个问题的方式很直接所有作业固定入口提交后端记录每个学生的提交状态未交名单一键导出催交消息按未交名单定向发送。界面一出来谁没交清清楚楚不用靠人肉记忆。1.2 考勤点名效率与诚信问题的双重挑战课堂考勤是大学里最消耗班长耐心的事情之一。传统做法是课间拿着名单念学号几十号人念一遍怎么也得两三分钟碰上重名或者有人代答还要反复确认。纸质签到更不靠谱一张纸传到最后一排前面的人帮后面的人代签笔迹都对不上。后来有人说用“定位打卡”但实际做过的人都知道纯前端定位很好骗——小程序可以让用户手动填写经纬度或者打开调试工具模拟位置。所以考勤系统的关键不在于前端能不能拿到坐标而在于后端如何校验坐标、时间、会话状态这些组合条件。我在这套系统里做了“时间窗口 位置半径 二维码会话”三重校验后面第 5 部分会详细讲。1.3 请假与投票流程散落和信息失真请假在大学的流程通常是学生私聊学委说“明天想请个假”学委口头答应再转告辅导员。到了期末要核查出勤记录时请假信息已经淹没在聊天记录里了学委还得去翻记录确认。如果是正式一点的请假需要提交纸质假条但纸质假条审批进度不透明学生不知道辅导员批了没有。投票的问题则更典型。班级评优、团员评议、班委选举这类事情需要匿名投票但微信群接龙和问卷工具要么不匿名要么能被刷票要么统计结果没有留痕证明。虽然班的投票不像公司股东大会那样需要严肃的法律效力但没有留存凭证结果一旦有争议就很麻烦。这四个场景的共性是数据产生在微信生态内但没有任何结构化存储和流转机制。所以系统的本质并不是做一个“小程序”而是把班级管理里那些非结构化信息转变成结构化数据和明确状态流转。2. 系统架构设计Python 后端和微信小程序是怎么配合的这类型系统的技术选型其实没有太多悬念。前端必须用微信小程序因为班级成员天然都在微信里扫码或者转发即可进入不需要额外装 App也不存在 IOS/Android 适配的问题。后端选择 Python主要原因是开发效率高、生态成熟、适合课程设计阶段快速迭代。2.1 为什么用微信小程序而不是 App 或者 H5如果做一个独立 App首先面临下载安装的门槛——没几个人会为了交作业专门装一个 App。H5 虽然免安装但调用微信登录、订阅消息、上传文件的能力都要通过微信内置浏览器间接实现体验远不如原生小程序流畅。小程序则介于两者之间轻量免安装、可以拿到微信授权身份、支持模板消息推送、开发成本也比 App 低一个量级。对于班委场景小程序能通过微信的分享机制快速冷启动。班长把小程序码发到班级群同学点开就能用打开率比“请下载 XX 软件”高得多。而且小程序的登录链路天生适合这种实名制场景——微信拿到 code后端换取 openid再用 openid 关联学号和姓名一步到位不需要像传统网站那样填手机号注册。2.2 后端框架选型Flask 与 Django 的取舍后端我选了 Flask 而不是 Django理由是Django 自带 Admin 后台、ORM、Migration、Form 校验等一整套全家桶非常适合“管理后台优先”的项目。但班级管理系统的前端是小程序数据接口以 JSON 为主Django 自带的那套模板系统和 Admin 对小程序客户端来说基本派不上用场反而显得重。Flask 轻量灵活项目结构完全自己控制单个入口文件就能跑起来Debug 和部署都很直观。对于这种业务链路不复杂、接口数量在二三十个以内的系统Flask 的维护成本明显更低。如果后续确实想要管理后台Flask-Admin 或者单独写几个页面也完全够用。数据库选用 MySQL 8.0ORM 使用 SQLAlchemy。没有选 SQLite是因为部署在云服务器上、多人并发访问时SQLite 的写锁冲突会非常明显尤其是考勤高峰期全班几十个人同时打卡的场景。MySQL 在锁粒度和并发控制上好得多部署成本也就多一条建库命令没有必要省。2.3 整体调用流程与数据流整个系统典型调用链路是微信小程序前端发送请求到后端 Flask APIFlask 经过 Token 鉴权后操作 MySQL返回 JSON 数据文件上传走 Flask 内置的上传接口静态文件由 Nginx 托管考勤模块中微信小程序端获取用户经纬度后传给后端后端在服务端完成距离计算和判定。这套架构的优点是边界清晰小程序只管展示和采集后端管业务规则和数据一致性数据库管持久化。最后只要把 Flask 服务挂到 gunicorn 后面再由 Nginx 转发 HTTPS 请求就能满足微信小程序正式环境对合法域名的要求。具体部署细节我会放在第 6 部分展开。技术栈汇总如下端技术方案说明小程序端微信小程序原生开发无需额外框架页面数量不多原生性能最好后端Python 3 Flask轻量、灵活适合接口型项目数据库MySQL 8.0以 InnoDB 引擎为主支持事务和行级锁ORMSQLAlchemy与 Flask-SQLAlchemy 配合减少手写 SQL 的复杂度部署Nginx gunicorn反向代理静态文件gunicorn 管理后端进程存储服务器本地目录作业附件和考勤头像等文件存放于云盘3. 数据库设计四块核心业务怎么建模才能不打架数据库设计是这类系统真正的分水岭。很多课程设计项目功能全做完了一跑起来就到处报错根子往往在表结构上。该用外键的地方没建索引、状态字段设计得不合理、角色没有和用户关联都会在后续开发中不断埋坑。3.1 用户与角色openid、学号和角色字段怎么放用户表是系统的地基我建议这样设计user 表 id INT 主键自增 openid VARCHAR(64) 微信openid唯一 student_no VARCHAR(20) 学号唯一 name VARCHAR(20) 姓名 class_no VARCHAR(30) 班级例如“软件工程2302班” role TINYINT 角色0学生 1班长 2学委 3辅导员 avatar_url VARCHAR(255) 头像 created_at DATETIME 创建时间很多同学会纠结“要不要单独建一个 role 表”。对于这个系统完全不需要。角色种类只有四种而且每一种角色的权限差异是固定的直接在 user 表里放一个 role 字段简单高效。如果以后要扩展成“社团管理系统”这种多组织、多角色复杂的场景才需要独立的角色和权限表大学班级管理范围内这么做反而画蛇添足。openid 是从微信接口获取的它是用户在当前小程序下的唯一标识。值得注意的是同一个用户在不同的小程序里 openid 是不同的所以如果以后要和别的系统联动需要关联 unionid现阶段只做家长班委管理openid 完全够用而且应该在用户表中作为唯一索引防止一个微信用户被重复绑定到多个身份。3.2 作业模块的两张表发布与提交分离作业模块用两张表作业表和提交记录表。homework 表 id INT 主键 title VARCHAR(100) 作业标题 content TEXT 作业内容描述 deadline DATETIME 截止时间 attachment_url VARCHAR(255) 教师端附带的作业文件 class_no VARCHAR(30) 发布作业的班级 publisher_id INT 发布人用户ID created_at DATETIME 创建时间 homework_submission 表 id INT 主键 homework_id INT 关联作业ID student_id INT 关联学生用户ID submit_time DATETIME 提交时间 content TEXT 学生提交的文字说明 file_url VARCHAR(255) 学生提交的文件路径 status TINYINT 0未提交 1已提交 2迟交 3被打回 score DECIMAL(5,2) 批改分数 comment VARCHAR(500) 批改评语作业表和提交记录表是一对多关系一个作业对应多条提交记录。这里强调一点提交记录不要只留着“已提交”状态还要有“打回”状态。我见过很多项目只保存是否提交老师想让学生修改重交的时候只能让学生再传一次新旧版本混在一起最后都不知道老师改的是哪份。加一个被打回状态学生重新提交时把旧记录标记为“废”保留一条有效记录逻辑就清晰了。3.3 考勤模块考勤事件与考勤明细的设计考勤模块的表设计容易犯一个错误把所有学生打卡记录直接堆成一张大表每次点名就新增几十条记录学期结束一张表几十万行查询还慢。正确做法是分成“考勤事件表”和“考勤记录表”。attendance 表考勤事件表 id INT 主键 class_no VARCHAR(30) 考勤班级 course_name VARCHAR(50) 课程名称 start_time DATETIME 考勤开始时间 end_time DATETIME 考勤结束时间 lat DECIMAL(10,6) 发起时教室纬度 lng DECIMAL(10,6) 发起时教室经度 creator_id INT 发起人用户ID create_time DATETIME 创建时间 attendance_record 表考勤记录表 id INT 主键 attendance_id INT 关联考勤事件ID student_id INT 学生用户ID check_in_time DATETIME 签到时间 lat DECIMAL(10,6) 签到时的纬度 lng DECIMAL(10,6) 签到时的经度 status TINYINT 0缺勤 1正常 2迟到 3请假 remark VARCHAR(255) 备注这样设计的好处是查询某一次考勤时只需要通过 attendance.id 过滤出该次考勤的几十条记录统计整个学期的出勤率时用 attendance_id 关联分组合计。考勤事件表存教室经纬度而不是硬编码在代码里这样每次换教室只需要在发起考勤时定位一次即可灵活很多。3.4 请假与投票模块状态流转与防重复请假表的核心是状态字段。请假申请不是一次性动作而是一个状态流转过程从“待审核”到“通过”或“驳回”。建议增加一个 leave_record 表记录审批过程如果流程比较简单只用一个字段也可以但至少要有记录修改人和修改时间的字段。leave_request 表 id INT 主键 student_id INT 学生用户ID leave_type TINYINT 事假/病假/其他 start_time DATETIME 请假开始时间 end_time DATETIME 请假结束时间 reason VARCHAR(500) 请假原因 attachment_url VARCHAR(255) 证明材料 status TINYINT 0待审核 1通过 2驳回 3已销假 auditor_id INT 审核人用户ID audit_time DATETIME 审核时间 audit_comment VARCHAR(255) 审核意见 create_time DATETIME 申请时间“销假”是一个容易被忽略的状态。学生请假结束后应该有一个销假动作不然考勤模块统计时会把已过期的请假记录直接当作缺勤处理。我在实际开发中遇到过类似问题——学生请了两天病假第三天没来上课系统里请假记录还挂着“通过”状态考勤统计就默认他还在假中。加了销假状态之后必须在请假结束日期后由学生主动提交销假或者系统定时自动判定考勤数据才算准确。投票模块需要防重复投票。用户接口层的判断永远不够必须在数据库层加唯一约束vote 表 id INT 主键 title VARCHAR(100) 投票标题 description TEXT 描述 class_no VARCHAR(30) 投票班级 start_time DATETIME 开始时间 end_time DATETIME 结束时间 is_anonymous TINYINT 是否匿名 created_by INT 创建人用户ID vote_option 表 id INT 主键 vote_id INT 关联投票ID option_text VARCHAR(100) 选项内容 vote_record 表 id INT 主键 vote_id INT 关联投票ID user_id INT 投票人ID option_id INT 选中的选项ID create_time DATETIME 投票时间 UNIQUE KEY unique_voter (vote_id, user_id)vote_record 表在正常投票场景下不需要公开用户和选项的对应关系但留着 user_id 是为了防重复管理员可以在需要时追查是否存在异常投票行为。如果在数据库层加上 (vote_id, user_id) 唯一约束那么即使接口层有并发漏洞数据库也会拒绝第二次插入这才是真正不可绕过的防线。4. 微信小程序端各角色看到的页面和交互逻辑小程序端的页面不需要很多一个首页工作台、四个业务模块的列表和详情页加上一个登录页和“我的”页面就足够支撑班级日常管理了。真正需要花心思的是不同角色看到的内容和操作按钮要有所区分。4.1 工作台首页按角色动态渲染入口登录之后小程序根据用户 openid 请求后端接口拿到用户信息前端根据 role 字段动态渲染首页按钮。学生看到的是“我的作业”“考勤签到”“请假申请”“投票中心”班长和学委额外看到“发起签到”“发布作业”“审批请假”“创建投票”。这里有一个设计细节不要把所有功能的入口都铺在同一屏上。班级管理场景里学生的核心高频动作不超过两个——交作业和签退。把这两个功能做成首页顶部的大按钮其他功能折叠在菜单里学生使用起来会顺畅很多。我把“今日是否有作业”“今日是否有考勤”作为首页的两个醒目卡片用户一点就能进入对应页面体验比堆满九宫格图标自然得多。4.2 考勤打卡页面如何防止“人在宿舍也签到成功”考勤打卡页的核心交互是学委发起签到并设置开始结束时间和有效距离范围学生进入页面后点击“签到”小程序通过 wx.getLocation 拿到当前位置连同用户 Token 一起提交后端。前端页面的核心逻辑onLoad() { // 获取考勤事件信息和当前定位 wx.getLocation({ type: wgs84, success: (res) { this.setData({ latitude: res.latitude, longitude: res.longitude }); } }); } handleCheckIn() { wx.request({ url: ${apiBase}/attendance/checkin, method: POST, data: { attendanceId: this.data.attendanceId, latitude: this.data.latitude, longitude: this.data.longitude }, header: { Authorization: Bearer ${token} }, success: (res) { if (res.data.code 0) { wx.showToast({ title: 签到成功, icon: success }); } else { wx.showToast({ title: res.data.msg, icon: none }); } } }); }有人会问前端把经纬度传上去后端怎么知道这个坐标是真实的很遗憾纯依靠前端定位无法完全防作弊因为用户可以修改模拟位置。但可以在后端加时间戳校验——考勤签到接口的判断逻辑是当前时间必须在考勤事件的有效时间窗口内签到位置必须在考勤事件设置的教室坐标一定半径范围内并且同一用户只能成功签到一次。这三个条件同时满足就返回成功。对于班级点名这种信任度场景已经足够拦住大多数“人不在现场直接打卡”的问题因为学生要伪造坐标还得同时保证时间对得上。4.3 作业提交和请假表单的交互细节作业提交流程的关键在于文件上传体验。微信小程序的 uploadFile 接口会把 multipart 表单请求发送到后端后端用 Flask 的 request.files 接收。前端要控制文件大小大文件建议先用 wx.compressImage 压缩图片再上传。我在实际测试中发现微信小程序由 wx.chooseMedia 选出的图片原图可能 5MB 以上但 Flask 默认配置的 MAX_CONTENT_LENGTH 如果不设置后端会用尽内存去接收大文件频繁出现超时。把限制设置成 10MB并在前端先做压缩两者配合才能顺畅。请假表单的交互重点是审批状态的及时反馈。提交请假申请后页面不能只显示“已提交”要展示完整的状态节点待审核、通过、驳回和销假。学生被驳回时能看到审批意见并重新编辑提交。班长审批时在请假列表页通过下拉刷新拉取最新申请每条申请卡片展示学生姓名、请假时间段、请假原因和证明材料缩略图一键通过或驳回。这样整个流程是闭环的不像聊天记录里的请假信息那样无法追踪。4.4 投票模块的匿名与实时统计投票页面的核心是保证“一人一票”和结果透明。前端在渲染投票选项时通过状态字段判断当前用户是否已投过票。已投票用户进入页面看到的是结果统计而不是选项按钮未投票用户看到的是可点击的选项列表提交后按钮立即变成“已投票”同时置灰。关于匿名的问题班级投票虽然希望匿名表达意见但技术上仍然会记录 user_id 用于防重复。真正的匿名票如果需要做到连管理员都查不到是谁投的就不能在 vote_record 表里直接存 user_id而是存一个由用户 openid 和服务端密钥共同生成的匿名 token这样既防重复又不可反查。班级内部的民主测评一般不需要做到这种程度所以我这里直接保留 user_id方便有问题时追溯。5. Python 后端 API 的关键实现鉴权、位置校验与审批流前端页面再花哨关键还是后端把规则执行住。这个部分我把几个核心接口的实现思路讲透。5.1 登录鉴权用 openid 换自定义 token 的完整流程小程序的登录逻辑大家都熟悉wx.login 拿到 code后端拿 code 向微信接口换 openid。很多人拿到 openid 就直接把 openid 存到本地每次请求都带上 openid 当身份凭证。这样做有两个隐患一是 openid 泄露之后就等于身份泄露其他人拿到你的 openid 可以冒充二是服务端吊销身份很麻烦如果发现异常没法把某个 openid 踢下线。所以我的做法是后端用 openid 查用户表成功则生成一个随机的 token 字符串存到 Redis 或者 MySQL 的一张 session 表里设置有效期并把 token 返回给前端。前端后续请求都在 header 里带Authorization: Bearer token后端每个接口先解析 token再从 session 表或 Redis 里拿对应用户信息。app.route(/api/auth/login, methods[POST]) def login(): code request.json.get(code) # 向微信服务器换取 openid resp requests.get( https://api.weixin.qq.com/sns/jscode2session, params{ appid: app.config[APP_ID], secret: app.config[APP_SECRET], js_code: code, grant_type: authorization_code } ).json() openid resp.get(openid) if not openid: return jsonify(code1, msg微信登录失败) user db.session.query(User).filter_by(openidopenid).first() if not user: return jsonify(code1, msg用户未绑定请联系管理员) token uuid.uuid4().hex # 存储到 session 表记录失效时间 session UserSession(user_iduser.id, tokentoken, expire_timedatetime.now() timedelta(days7)) db.session.add(session) db.session.commit() return jsonify(code0, data{ token: token, user: { id: user.id, name: user.name, role: user.role, classNo: user.class_no } })token 过期时间的设定要合理。太短影响体验学生可能上午登录下午就过期了要重新登录太长不安全账号被别人拿到后可以长时间冒充。七天是一个折中值配合前端在请求返回 401 时自动跳转登录页体验上基本无感。如果使用 Redis 做 session 存储可以很方便地删 key 实现踢人这套系统规模不需要 Redis我用的是 MySQL 存储 session效果相同。5.2 考勤签到的后端校验逻辑考勤签到的核心函数大概是这样的app.route(/api/attendance/checkin, methods[POST]) def checkin(): user current_user() data request.get_json() attendance_id data[attendanceId] lat float(data[latitude]) lng float(data[longitude]) att db.session.query(Attendance).filter_by(idattendance_id).first() if not att: return jsonify(code1, msg考勤事件不存在) if att.end_time datetime.now() or att.start_time datetime.now(): return jsonify(code1, msg不在考勤时间内) # 计算与教室的距离 distance haversine(att.lat, att.lng, lat, lng) if distance att.radius: return jsonify(code1, msgf距离教室过远当前距离约{distance:.0f}米) record db.session.query(AttendanceRecord).filter_by( attendance_idattendance_id, student_iduser.id).first() if record and record.status ! 3: return jsonify(code1, msg不能重复打卡) # 迟到判断晚于开始时间 15 分钟 status 1 if datetime.now() att.start_time timedelta(minutes15) else 2 record AttendanceRecord( attendance_idattendance_id, student_iduser.id, check_in_timedatetime.now(), latlat, lnglng, statusstatus ) db.session.add(record) db.session.commit() return jsonify(code0, msg签到成功)这里面的 haversine 函数是 WGS84 坐标系下计算两个经纬度点球面距离的标准方式公式固定网上能查到也可以直接写函数体。需要注意 lat 和 lng 不能从前端直接信任后端要用 Decimal 转换防止 NaN 注入。之前看到有同学用 float 然后直接把数据存库MySQL 对 NaN 会直接报错前端又难以排查原因所以防御性代码写上不会亏。5.3 请假审批状态机的实现思路审批流程可以用一个简单的状态机来实现。学生提交请假后记录状态为 0待审核班长审批通过则置为 1驳回则置为 2学生确认返校后点击销假状态置为 3。前端的状态切换和按钮渲染都要以后端返回的状态为准不能由前端直接修改状态的字段。我在系统里的原子动作是“审批”而不是“改状态”——审批接口内部根据当前状态和操作类型决定下一状态是否合法。比如一个已经“通过”的请假单不能再次被“审批通过”否则会产生歧义。如果请假审批需要多级学生 - 学委 - 辅导员可以在 leave_request 表增加 current_level 字段表示当前审批到哪一级。每级审批通过后 current_level 自动加一直到最终 level 大于最大层级状态变为通过。这样“审批层数”和“审批结果”解耦代码不会写成面条式的一串 if-else。5.4 投票防重复与 Excel 导出投票接口的核心是数据库唯一约束兜底。接口实现顺序是先查当前用户有没有投过再插入记录最后统计结果。如果是在高并发场景两个请求同时通过第一步校验又同时插入有唯一约束也能保证只有一个成功。投票结果统计可以用一条 SQLresults db.session.query( VoteOption.id, VoteOption.option_text, func.count(VoteRecord.id).label(cnt) ).outerjoin(VoteRecord, VoteRecord.option_id VoteOption.id ).filter(VoteOption.vote_id vote_id ).group_by(VoteOption.id).all()Excel 导出是班主任最常用到的功能。我使用 openpyxl 库把考勤记录、作业提交记录、请假记录按筛选条件导出成 xlsx。这里有一个经验不要直接在接口响应里返回二进制文件流给小程序小程序在 webview 环境下对二进制流的处理能力受限。更稳妥的做法是后端生成 Excel 文件保存到服务器返回一个可访问的文件 URL小程序端再用 wx.downloadFile 下载并用 wx.openDocument 打开预览。这样兼容性最好也方便后续把文件挂到班级公告里。6. 部署上线避坑记录从“本地能跑”到“全班能用”的距离很多项目在本地跑得风生水起一到真机测试就各种问题。我挑几个最常见、最影响体验的坑展开聊。6.1 合法域名和 HTTPS 是上线的第一道门槛微信小程序正式环境对网络请求有严格限制request 的域名必须在小程序后台配置为合法域名并且必须是 HTTPS不支持 IP 地址不支持自签名证书。这意味着如果你的服务器只有 IP 地址开发工具里能通过“不校验合法域名”绕过但手机真机预览时绝对无法访问。解决方案只有一条买一个域名备案中国大陆服务器必须备案然后给域名配置 SSL 证书。现在各大云厂商有免费证书申请安装到 Nginx 上十分钟能搞定。别拖到上线前几天才搞这步备案流程最快也得一两周提前准备才是明智的。6.2 并发、超时与文件上传的隐藏限制考勤高峰期可能出现全班瞬间同时签到。如果后端使用 Flask 自带的开发服务器性能会非常拉胯。生产环境一定要用 gunicorn 部署至少配置 4 个 worker。另外MySQL 连接池需要设置合理大小默认的 SQLAlchemy 连接池在并发 30 多个请求时就会出现连接等待我建议使用 pool_size10, maxoverflow20。不然开学第一次上课全班打卡就可能出现大半人“签到失败”。文件上传方面nginx 的 client_max_body_size 默认只有 1MB必须调到 20MB 以上否则作业图片稍微大一点就传不上去。同时 Flask 端的 MAX_CONTENT_LENGTH 也要同步配置不然 Nginx 过了Flask 又报错。6.3 数据导出与备份的日常工作习惯班级管理系统的数据量虽然不大但作业和考勤记录对学分评定很重要。养成每天自动备份的习惯写一个 crontab 脚本在凌晨导出 MySQL 到云盘成本很低但价值巨大。如果学校没有数据恢复机制服务器磁盘挂了整个班一学期的考勤记录就全没了这种事故谁也担不起。部署时还要注意不要用 root 账号直接跑数据库应用创建专用账号并配置最小权限服务器安全组别把 3306 对公网开放MySQL 只允许内网访问后端应用通过内网 IP 连接。这些属于基础操作但我见过不少课程设计项目把 3306 端口直接暴露到公网结果没几天数据库就被黑。下面是一张常见问题排查表都是我实际踩过或帮别人排查过的问题表现根本原因解决办法手机预览请求全失败未配置合法域名或证书无效后台配置域名并完成 ICP 备案图片上传报 413Nginx 请求体限制默认 1MB修改 client_max_body_size全班同时打卡部分失败开发服务器单线程或连接池太小改用 gunicorn 并增加 worker、调大连接池用户切换微信账号后数据串号登录逻辑把 openid 存本地不回源每次启动通过 code 重新登录换取 token投票能投两次接口层未做用户去重数据库增加唯一约束7. 几个值得继续深挖的扩展方向班级管理系统做到作业、考勤、请假、投票四块之后基本盘已经稳了但还有几个边界场景可以让系统的价值再上一个台阶。第一个是课表管理。如果能接入教务系统的课表考勤事件就不用手动创建直接按照课表每个上课时间自动生成考勤事件学生到课即打卡学委只需要做异常修正工作量能再降一半。不过课表数据需要从教务系统拿到有些学校有开放 API有些只能靠手工导入 Excel这一步要视学校情况而定。第二个是成绩管理。平时的作业成绩、考勤分数按权重自动汇总期末一键生成本课程的平时成绩单。这个功能其实只需要在作业表和考勤记录上多做两步聚合计算但能帮老师省下大量手动整理的时间。第三个是班级通知模板消息。利用微信订阅消息在作业发布、考勤创建、请假审批结果出来时向相关学生推送通知。相比让学生主动打开小程序查看订阅消息能显著提升系统的触达率。需要注意的是小程序订阅消息一次授权只能推送一次用户拒绝授权后就不能再推需要设计好授权策略。第四个是数据可视化。学委和老师可以在后台看到出勤率走势、作业提交按时率、请假原因分布等图表。数据量积累一个学期之后这些图表能直观反映班级整体状态也为评奖评优提供数据支持。这些扩展方向不需要推翻重构基于现有表结构和 API 能力都能逐步叠加。我个人的建议是先把考勤和作业这两块用得滚瓜烂熟再考虑扩展。因为这两块是班级管理里最高频、最有痛点的功能用户用得好了后面加投票、请假等功能自然水到渠成一上来就全功能铺开反而容易让使用者眼花缭乱。最后再分享一个我踩过的小坑第一次上线时我在后端把经纬度比较的距离阈值写成了 50 米觉得教室半径 50 米肯定够宽松。实际测试发现在室内 GPS 漂移严重的时候站在教室正中央定位精度可能漂出 80 米。后来我把阈值调整成 150 米并增加了考勤事件创建时“由创建者先定位到教室位置”的机制才算稳定下来。这类细节不跑到真机上永远发现不了也正说明了为什么这类系统一定得尽早让真实用户在真实场景里用起来。