基于Django与微信小程序的大学生心理测评系统实战开发

1. 先把需求想清楚：一张缺勤统计表回答不了“为什么没来”

1.1 从出勤异常到心理疏导，才是这套测评系统存在的意义

我接触这个项目的起因，是朋友所在学院需要一个能辅助学生工作的工具。当时他们手里已经有一套考勤系统，能精确统计出某个学生这学期缺勤了几次、集中在哪几门课，甚至能画出按班级、年级的缺勤折线图。但每次把这些数据摆在辅导员面前，大家都会陷入同一个问题：知道了谁经常不来，然后呢？

直接批评或者处分，容易让本来就有学业压力的学生更加抗拒；什么都不做，又会眼看着学生从偶尔缺勤走向持续脱离课堂。于是话题自然转向了“能不能在考勤之外多采集一层信息，判断学生缺勤背后到底是学习动力不足、情绪状态不好、还是单纯的作息失控”。这个诉求落到产品形态上，就是一套面向大学生群体的心理测评系统，而前端载体选了几乎人人都在用、不用额外安装的微信小程序。

这套系统的核心闭环并不复杂：学生在小程序里完成一份不长的心理问卷，后端使用 Python 和 Django 提供问卷下发、提交、计分、报告生成等接口，辅导员或心理老师在小程序端或管理后台查看群体结果。它解决的不是“如何阻止逃课”，而是“如何发现需要被关注的苗头”。我特别强调这一点，是因为如果一开始把目标定义成“识别逃课并惩罚”，那这个系统一定做歪，也会在价值观上站不住。

1.2 测评不是诊断，系统边界划定在“辅助参考”

做心理相关内容，最忌讳的是把一份自评量表包装成诊断工具。大学生逃课心理测评，背后的量表维度可以涉及学习倦怠、情绪状态、社交回避、自我控制、专业认同等，但量表的输出结果只能叫“风险提示”或者“倾向性描述”，绝对不能出现“你有某病”这类表述。

我在确定字段时，测评记录里预设了一个 risk_level，分低、中、高三档。低风险报告给学生的文案是中性的成长建议；中风险会提示学生可以主动预约心理中心或找辅导员聊聊；高风险则不会在小程序端直接渲染成吓人的结论，而是在后台给辅导员可见的预警，并附带一句“建议由校心理中心或辅导员进一步了解情况”的话术。这个设计既保住学生的自尊心，也让系统真正可落地。

真正的高风险结果如果直接当着学生的面弹出“您存在严重问题”，恐怕没有几个人敢如实提交问卷。所以系统边界必须拿捏好：学生端看到的是“状态晴雨表”，管理端看到的才是“需要跟进的学生名单”。这个思路也希望大家在自己的项目里多考虑，尤其是医学、心理、法律这类敏感业务，宁可为伦理多设计几个字段，也不能让系统输出显得武断。

1.3 三类使用者的诉求各不相同

• 学生用户：打开小程序后看见的应该是“最近有节状态评估”的邀请，而不是“逃课心理测试”这种带审判意味的名字。他们的真实诉求是隐私、简单、能快速完成，提交之后能得到不尴尬的反馈。
• 辅导员/心理老师：需要群体统计结果，比如全院近一个月的测评分布、各分数段人数、需要特别留意的学生是谁，以便线下有针对性地谈心。
• 系统管理员：负责维护量表题库、开关测评周期、配置问卷版本，管理员最好不用写代码就能完成日常运营。

所以后端虽然用 Django 开发，但我没有只写小程序所需的那几个 API，而是把 Django Admin 也充分利用起来。量表维度、单道题目、测评批次、学生账号的冷启动导入，全部可以直接在 Admin 后台维护。这样开发完以后，真正运营系统的人不需要你随时在边上改数据。

2. 选型复盘：Django做后端、微信小程序做前端的真实理由

2.1 Django 在这种校园内部业务里节省的工作量远超想象

后端框架有很多选择，Flask、FastAPI、Spring Boot 都可以做测评问卷接口。但我最终选了 Django + Python，不只是因为标题里写了这个技术栈，而是因为在“需要用户体系、需要后台管理、需要快速建模、团队还要能看懂”这四个条件下，Django 是综合成本最低的。

Django 自带 Admin 后台，测评项目天然需要一套题库维护界面。如果我用 FastAPI，Admin 这块要么自己写一遍增删改查页面，要么额外集成一套 React 后台，工程量会翻倍。用 Django 的时候，我只需要把几个模型注册进 admin.py，管理端的增删改查、搜索筛选、分页就全部有了。管理员甚至能在 Admin 里看到每个学生的历史测评提交时间，并按风险等级筛选出预警名单。

另一个隐性好处是 Django ORM。问卷系统要反复做聚合查询，例如“某一量表下所有学生的平均维度分”“近两周答题人数趋势”。用 ORM 可以快速组合出 aggregate 和 annotate 查询，不用为统计需求专职写 SQL。对于开发周期只有几周的项目来说，这个优势非常值钱。

2.2 为什么是微信小程序而不是 H5 页面

校园场景里，网页链接的传播路径其实很尴尬。学生收到一条网址，要先复制、打开浏览器、加载、可能还要登录，流失率非常高。微信小程序则直接集成在微信里，学生扫码或搜索后打开即用，答题过程中切出去回消息再回来也不会丢失页面状态。

开发时也顺手解决了一个常见问题：微信小程序和公众号一样，用户基本信息通过 wx.login() 拿到 code，后端再用 code 换取 openid。这个身份体系天然匿名化，你可以拿到一个用户在系统内唯一的 openid，却拿不到手机号或真实姓名。考虑到测评数据的私密性，这种轻量身份方案反而比强制手机号注册更容易让学生愿意参与。

2.3 前后端不是完全分离，也可以做到分工清晰

现在流行 Vue/React 写 SPA，再让 Django 只暴露 JSON API。但测评系统这种重流程、轻展示的项目，微信小程序本身就是独立的渲染端，天然就是前后端分离的形态。所以我完全不用操心页面路由归谁管，小程序的 pages 目录就是前端路由，Django 只负责数据协议。两者用 RESTful API 对接，前后端甚至可以让两位开发同学并行推进。

最终技术栈清单如下：