校园学生心理健康系统这几年需求量增长很快，几乎每个学段都在布局。我前后参与过几个类似的信息化项目，其中一套基于 Django + Flask 组合搭建的校园学生心理健康系统，算是在投入产出比上做得最平衡的一版。整套系统覆盖了心理测评、档案管理、预警干预、咨询预约、家校联动几个核心场景，前端用的轻量模板加少量原生 JavaScript，服务端拆成了 Django 主应用与 Flask 报告服务，部署在一台 4 核 8G 的云主机上，支撑两千人规模的中学绰绰有余。
这篇文章我把整个项目的需求分析、技术选型、数据库设计、核心模块实现、部署经验、踩坑记录全部摊开来讲。无论你是准备从零写一版毕业设计，还是学校/机构里负责信息化的老师想评估自建系统的可行性，这篇内容都能直接抄作业。
1. 项目概述与核心需求拆解
1.1 校园心理健康管理到底缺什么
接触过一线德育工作的朋友应该都有同感：校园心理工作最大的痛点不是缺咨询师，而是缺一套能把“筛查-评估-干预-跟踪-转介”串起来的信息化工具。大部分学校目前还在用 Excel 表格统计测评结果，用微信群收发预约申请，用纸质档案袋装咨询记录。这种模式在班级规模超过三十个之后就基本跑不动了，数据的时效性、准确性、安全性都存在很大隐患。
所以我做这个系统时，第一原则不是“功能越炫越好”，而是先把核心链路跑通。所谓核心链路，就是一条完整的学生心理服务闭环：
学生登录 → 填写心理健康测评量表 → 系统自动计算得分并生成评估等级 → 达到预警阈值时自动通知心理老师 → 心理老师查看测评详情、建立/更新心理档案 → 安排咨询预约 → 咨询师填写咨询记录 → 系统跟踪多次测评趋势 → 需要时向班主任/家长推送干预建议。
这个闭环拆成功能模块来看，大致就是六大块：学生信息管理、心理测评管理、预警与干预、咨询预约管理、心理档案管理、数据统计与报告。每一块都有业务上的坑，后面章节我逐个讲。
1.2 用户画像与角色权限设计
任何管理系统第一步都要想清楚有哪几类人用，各自能看什么、能改什么、不能碰什么。心理健康系统的权限设计比普通 OA 系统更敏感，因为涉及学生隐私和心理状态这种高度保密的数据。
我最终确定的角色体系是五类：
| 角色 | 核心权限 | 敏感数据可见范围 |
|---|---|---|
| 系统管理员 | 用户管理、系统配置、数据备份 | 全部（但建议操作留痕） |
| 心理老师 | 测评管理、预警处理、咨询预约、档案维护 | 全部学生心理数据 |
| 班主任 | 查看本班学生预警状态、填写日常观察记录 | 仅本班学生基础信息+预警等级 |
| 学生 | 填写量表、查看个人测评报告、在线预约 | 仅本人数据 |
| 家长（可选） | 查看学校推送的反馈、填写家庭观察记录 | 仅本人子女的非敏感评估摘要 |
这里有个设计细节值得强调：家长端绝不应该默认开放查看完整测评报告。中学生心理测评中涉及自我伤害、家庭关系、抑郁倾向等敏感维度，家长直接看到原始得分可能引发亲子冲突甚至更严重的后果。我在系统里做了“双版本报告”——学生端和咨询师端看到的是完整版，家长端和班主任端只能看到脱敏后的结论性建议，比如“近期压力水平偏高，建议多陪伴倾听”。
1.3 非功能性需求的权衡
除了显性功能，还有几个非功能需求在项目启动前就得定下来，否则后期返工成本极高。
- 并发量：全校统一安排心理测评时，可能同时涌进几百个请求。Django 同步阻塞模型在高并发下容易被打满，我的方案是 nginx 做反向代理 + gunicorn 多 worker 进程，实测 500 并发测评提交没有出现超时。
- 数据安全：心理健康数据属于敏感个人信息，等保二级的基本要求要满足。数据库密码加密存储、会话用 Redis 管理、测评数据操作记录日志。传输层全站 HTTPS，这个在校内局域网部署时容易被忽略。
- 易维护性：学校里的信息化系统经常面临开发人员离职后没人敢动的情况。所以项目结构要简单清晰，注释写明白，管理后台尽量用 Django 自带的 Admin 二次开发，不要为了“架构感”引入大量复杂依赖。
这三条框架确定后，技术选型就是顺势而为的事。
2. 技术选型与架构设计思路
2.1 为什么用 Django 做主体，Flask 做报告服务
选型时核心纠结过三个方向：全 Django、全 Flask、Django + Flask 混搭。
先说 Django。这东西最大的优势是“全家桶”——ORM、Admin、表单、认证、中间件、迁移工具都内置好了。心理健康系统这种重数据管理、重后台操作的业务，用 Django 能省掉大量重复造轮子的时间。而且 Django Admin 稍微定制一下就是一个堪用的管理后台，心理老师不用培训就能上手。对于校园项目来说，这太关键了。
那为什么还要引入 Flask 做报告服务？原因在于高频次的报告导出场景。学生每次心理测评通过后都要生成个人评估报告，心理老师还会定期做年级、班级的整体汇总报告和趋势分析。这些报告包含大量图表和数据拼装逻辑，本质上是一个相对独立的计算密集型任务。如果全部跑在 Django 主进程里，一旦学生集中测评，报告生成的耗时请求会把主应用拖慢。
所以我把“数据管理”和“报告生成”做了物理拆分：
- Django 主应用：用户管理、测评流程、预警干预、预约管理、档案维护。
- Flask 服务：接收 Django 传来的数据请求，生成 PDF/Excel 报告，提供图表渲染服务。
- 两者之间通过内部 HTTP 接口通信，Flask 服务不直接暴露给外网，只监听内网端口。
这个架构看起来“双框架”，实际维护成本并没有翻倍，因为 Flask 端只干一件事。它换来的是主应用的稳定性和报告生成的可扩展性，比如后期要做自动定时推送年级报告，只需要在 Flask 端加个定时任务，完全不影响主流程。
2.2 数据库选型与核心表结构设计
数据库我没有犹豫，直接选了 MySQL。PostgreSQL 也很好，但考虑到后期运维的人可能更熟悉 MySQL，而且 Django ORM 对两者的支持差异不大，MySQL 5.7 以上版本用起来已经非常省心。表结构设计和表引擎，因为涉及事务和行级锁，统一用 InnoDB。
整个库我设计了十五张表，这里把核心的几张拿出来说说：
学生信息表（student_profile）：账号、姓名、学号、年级、班级、性别、入学年份、状态等。注意不要和 User 表合并。Django 自带 User 表存认证信息，StudentProfile 专门存学生业务属性，一对一来关联。这样设计和将来扩展新身份类型（教师、工勤人员）互不干扰。
测评量表配置表（scale_config）：量表名称、题目编号、维度说明、评分规则、适用年级范围。这张表的意义在于“量表可配置”。市面上的量表很多，SAS、SDS、MHT、SCL-90、中学生心理健康量表都不一样，不同的学校可能用不同的版本。把量表做成配置化，换量表就不用改代码，只要在后台录入新量表和评分规则即可。
测评记录表（assessment_record）：学生、量表、各维度得分、总分、评估等级、测评日期、测评状态。这张表是系统的核心中的核心。所有筛查数据都在这里，预警判断、趋势分析、报告生成都要查它。
预警记录表（alert_record）：学生、测评记录、预警等级、预警时间、处理状态、处理方式、处理人。每次测评触发预警就生成一条记录，后续干预动作全部挂在预警记录下面，方便追溯。
咨询预约表（appointment_record）：学生、咨询师、预约时间段、状态（待确认/已确认/已完成/已取消）、咨询类型（初访/定期/紧急）。预约模块要特别注意时间冲突问题，我单独做了唯一索引约束。
这几张表之间最核心的一条业务链就是：student_profile → assessment_record → alert_record → appointment_record → 咨询记录。只要顺着这条链走，整个系统的数据流就不会乱。
2.3 项目目录结构规划
目录结构直接影响后续可维护性。我最终使用的结构是：
psych_system/ ├── manage.py ├── config/ # Django 主配置 │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── accounts/ # 用户认证与角色管理 │ ├── students/ # 学生信息管理 │ ├── scales/ # 测评量表管理 │ ├── assessments/ # 测评流程引擎 │ ├── alerts/ # 预警与干预 │ └── appointments/ # 咨询预约与记录 ├── report_service/ # Flask 独立报告服务 │ ├── app.py │ ├── pdf_generator.py │ ├── chart_builder.py │ └── templates/ ├── static/ └── templates/每个业务模块独立成一个 Django App，互不越界。核心业务逻辑写在services.py里而不是散落在 view 函数中——这是多项目实践总结出来的经验，逻辑集中在 service 层，测试和维护都轻松得多。
3. 核心功能模块与关键实现细节
3.1 测评引擎：可配置量表与自动评分
测评模块是整个系统的技术核心，也是业务核心。我参考了多套开源心理测评系统的做法，把测评流程抽象成一个“配置驱动”的引擎。
用户在前端看到的是一套带进度条的测评页面，每页展示 5-8 道题，题型基本是李克特五级评分（完全不符合、比较不符合、一般、比较符合、完全符合）。学生提交答案后，后端做两件事：逐题计算小维度的得分，再汇总总得分或标准分，最后根据量表的常模规则映射出评估等级（正常/轻度/中度/重度）。
这个过程中有几个关键细节值得讲：
评分规则的存储方式。评分规则不要硬编码在代码里。我把评分规则做成 JSON 字段存在scale_config表里，格式大致像这样：
{ "scores": { "answer_1": 1, "answer_2": 2, "answer_3": 3, "answer_4": 4, "answer_5": 5 }, "reverse_scoring": [3, 8, 12], "dimensions": { "anxiety": [1, 4, 7, 10], "depression": [2, 5, 8, 11], "social": [3, 6, 9, 12] }, "thresholds": { "normal": [0, 40], "mild": [41, 50], "moderate": [51, 60], "severe": [61, 100] } }reverse_scoring字段是反向计分题，这部分最容易做错。很多量表里有反向陈述的题目，比如“我觉得生活很有趣”，选“完全不符合”反而说明心理状态可能有风险，这类题目的计分必须反转（5 变成 1，4 变成 2，以此类推）。
评分引擎拿到配置后，按维度聚合得分，再配合常模数据进行判断。常模数据的意义在于让原始分可以对照同年龄段群体的标准进行比较。我维护了一张norm_reference表，按年级段和性别存放均值和标准差，计算标准分的时候直接用公式：标准分 = 50 + 10 ×（原始分 - 均值）÷ 标准差。
这块是心理测评的核心算法逻辑，不容出错。写完之后一定要请心理学背景的老师帮助验算一遍，拿一批已有的纸质测评结果做对照，确认得分和等级完全一致才算通过。
3.2 预警规则：分层提醒与闭环干预
测评完后最重要的就是预警处理。系统把预警分为三个等级：
- 一级预警（红色）：测评结果达到重度风险，或者出现自伤相关题目的高选项答案。系统即时通过短信 + 站内信通知心理老师和年级组长，并在工作台置顶展示，要求 24 小时内完成一对一访谈。
- 二级预警（橙色）：中度风险。系统通知心理老师和班主任，要求一周内完成访谈并记录。
- 三级预警（黄色）：轻度风险，系统仅做记录存档，由心理老师根据情况决定是否约谈。
这个等级的划分也和测评量表的评估等级对应，但在执行层面额外引入了“心理老师确认”的环节。也就是说，测评结果的预警是系统的自动判断，它提醒老师“这个学生需要关注”，但真正的干预动作必须由老师确认后实施。系统设计上避免直接用机器判定替代人工专业判断，这是校园心理工作伦理的基本要求。
预警处理流程在alerts应用里是这样的：
测评完成 → 触发预警规则判断 → 写入 alert_record → 推送通知 → 心理老师查看并标记“已关注”→ 填写访谈/处理记录 → 状态变为“已结案”→ 系统停止重复预警这里还有一个场景容易忽略：同一个学生在多次测评中都触发预警怎么办？如果每测一次就生成一条新预警，后台会被刷屏。我的处理方式是每次测评都生成新的预警记录，但如果在同一个学期内同一类等级已经存在“未结案”的预警，则自动追加到原记录下而不是新建一条，只有在原记录状态变为“已结案”之后，再次触发高等级预警才产生新记录。这样既能完整追溯学生在不同阶段的测评结果变化，又不会造成信息轰炸。
3.3 咨询预约模块：避开时间冲突的细节设计
咨询预约看起来简单，实际时间冲突问题特别容易踩坑。
一条预约记录要关注三个时间维度：学生申请时间、咨询师确认时间、实际咨询时间。我设计了两个状态字段，一个叫booking_status（待确认/已确认/已完成/已取消），一个叫cancel_reason（学生取消/老师取消/超时未确认/已结案取消）。系统里通过一个 Python 函数来校验时间冲突：
def check_consultant_available(consultant_id, start_time, end_time): conflicts = AppointmentRecord.objects.filter( consultant_id=consultant_id, status__in=['confirmed', 'pending'], start_time__lt=end_time, end_time__gt=start_time, ) return not conflicts.exists()这段逻辑思考起来简单，但很多人写预约系统时会忽略“待确认”状态也算占用时间。如果系统允许学生申请某个时间段，但老师还没确认，另一个学生又申请了同一时间段，就必须给出提示“该时间段已被申请，请选择其他时段”。如果不这样处理，就会出现两个学生约到同一个咨询师同一时间的状况。
另外预约功能还做了“咨询类型”区分。初访是首诊评估，定期是持续的咨询复访，紧急是针对突发事件的心理援助。紧急预约需要绕过正常排队逻辑，直接显示在咨询师工作台最顶部。校园场景里突发情况并不少见，这条逻辑是心理老师提的需求。
3.4 心理档案与趋势追踪
学生心理档案不是一次测评结果的快照，而是一个动态追踪的集合。每一条测评记录、每一次咨询记录、每一份访谈记录，都挂在这个学生的档案下面。心理老师点开一个学生的档案，看到的是他从高一入学到高三毕业的心理变化曲线。
趋势分析功能的实现用的是 Django ORM 查询 + ECharts 前端绘图。后端接口返回一个学生在某一量表上历次测评的总分变化数组，前端渲染成折线图。折线图最大的价值是发现“持续走低/持续走高”的规律。比如一个学生三次测评的得分分别是 35、42、55，明显是一个情绪持续恶化的趋势，这时候即使第三次测评结果只是中度风险，系统也会在趋势图上打一个“注意力”标记，提醒咨询师关注。
档案模块还有一个重要设计——平行档案。学生的心理档案里，测评记录和咨询记录属于两个安全级别。测评记录经过自动评分，数据客观量化；咨询记录是咨询师的主观记录和判断，可能包含非常敏感的口述信息。我把这两个子模块的访问权限做了区分：测评记录对心理老师和年级组长可见，咨询记录仅心理老师本人和部门负责人可见。这种细粒度权限控制，可以在满足协同需求的同时最大限度地保护学生隐私。
4. 实操过程与核心环节实现
4.1 环境准备与项目初始化
环境我用了 Python 3.10 版本，Django 4.2 LTS，Flask 2.3，MySQL 8.0。为什么没用最新的 Django 5.x？因为 4.2 是长期支持版本，安全更新周期更长，对校园这种不太频繁升级的部署场景更合适。
初始化步骤：
# 创建虚拟环境 python -m venv psych_env source psych_env/bin/activate # 安装依赖 pip install django==4.2.* mysqlclient pillow djangorestframework django-cors-headers flask flask-cors reportlab openpyxl requests # 创建项目 django-admin startproject config . python manage.py startapp apps/accounts python manage.py startapp apps/students python manage.py startapp apps/scales python manage.py startapp apps/assessments python manage.py startapp apps/alerts python manage.py startapp apps/appointments这里有个小技巧：Django 默认的startapp命令创建的应用目录不一定能直接识别apps/这个子目录作为包。需要在config/settings.py中加上sys.path.insert(0, os.path.join(BASE_DIR, 'apps'))，然后 INSTALLED_APPS 里直接写'accounts'、'students'这样的短名称就行。
数据库配置文件用环境变量来管理，不要硬编码在 settings.py 里。我习惯备一个.env文件，然后借助python-dotenv加载。这样换部署环境的时候只需要改.env，代码完全不动。
4.2 用户认证与角色控制的实现
认证部分直接用 Django 自带的AbstractUser扩展。给 User 表加一个role字段，角色枚举设为admin、psychologist、headteacher、student、parent，然后写一个自定义的PermissionMixin做视图级权限控制。
class PsychPermissionMixin: allowed_roles = [] def dispatch(self, request, *args, **kwargs): if request.user.role not in self.allowed_roles: raise PermissionDenied return super().dispatch(request, *args, **kwargs)需求里班主任的权限是“仅本班数据”，这就需要在视图里额外做班级 ID 的校验，不能只靠角色判断。比如，班主任登录后试图访问其他班学生的档案，即使他拥有headteacher角色，也必须被拦截。我给所有涉及学生数据的查询都加了一个get_queryset方法重写，在基础查询条件上自动拼上班级过滤条件。
4.3 测评页面的前后端实现
测评页面前端我不想用太重的框架，就用原生 JavaScript + AJAX 处理。测评过程中的关键点是不要让页面刷新，否则学生的答题进度可能会丢失，引发烦躁情绪。我用一个全局的currentIndex变量记录当前答题进度，答题后立即把答案暂存到 localStorage，同时异步发送到后端保存“未完成状态”。如果学生中途退出，下次进来可以接着做。
测评提交的后端视图核心逻辑长这样：
@login_required def submit_assessment(request, scale_id): if request.method == 'POST': answers = json.loads(request.body).get('answers', []) scale = ScaleConfig.objects.get(id=scale_id) # 调用评分引擎 raw_score, dimension_scores = score_calculator.calculate(scale, answers) standard_score = score_calculator.to_standard_score( raw_score, scale, request.user.student_profile ) level = score_calculator.get_level(standard_score, scale) # 写入测评记录 record = AssessmentRecord.objects.create( student=request.user.student_profile, scale=scale, raw_score=raw_score, standard_score=standard_score, level=level, detail_scores=json.dumps(dimension_scores) ) # 生成预警 alert_engine.check_and_create(record) return JsonResponse({ 'status': 'success', 'record_id': record.id, 'level': level, 'redirect_url': f'/assessment/detail/{record.id}/' })这段代码把链路串起来了：答题提交、评分、写入记录、预警检查，一气呵成。学生端测评完成后立即看到结果页面，同时预警已经静默生成，等待心理老师处理。
4.4 Flask 报告服务与 PDF 生成
Flask 端我专门做了一个/api/report/student/接口，接收学生 ID 和报告类型参数，然后去 MySQL 查询对应的测评、趋势、咨询记录数据，用 ReportLab 库动态生成 PDF 报告。生成的报告包含基础信息、本次测评得分、维度分析雷达图、多次测评趋势折线图、评估结论和建议。
PDF 生成时踩过最大的坑是中文字体。ReportLab 默认字体不支持中文，生成的 PDF 会出现乱码。解决方案是准备一个开源的中文字体文件放到 static 目录下，并在生成时注册：
from reportlab.pdfbase import pdfmetrics from reportlab.pdfbase.ttfonts import TTFont from reportlab.lib.styles import ParagraphStyle pdfmetrics.registerFont( TTFont('NotoSansCJK', 'static/fonts/NotoSansCJKsc-Regular.otf') )注册后所有的标题、正文、表格都指定这个字体，中文显示就正常了。生成报告后通过 HTTP 把文件流返回给 Django，用户在浏览器里直接下载。
这里也建议把 Flask 服务的管理命令写成一个 Shell 脚本，方便手工重启或者加入系统任务计划。脚本内容很简单：激活虚拟环境、启动 gunicorn、绑定 127.0.0.1:5001 端口。
4.5 部署方案与性能配置
部署环境的整体拓扑是：
nginx (80/443) └── gunicorn (Django, 127.0.0.1:8000) └── MySQL 8.0 (127.0.0.1:3306) └── Redis (127.0.0.1:6379) # 会话和缓存 └── gunicorn (Flask, 127.0.0.1:5001)nginx 配置里最需要注意的是静态文件处理。我把 Django 的STATIC_ROOT指定到/var/www/psych_system/static，交给 nginx 直接服务，而不是经过 Django。这样能大幅减少 Python 进程的压力。上传的附件类文件（比如学生提交的图片附件）单独存到/var/www/psych_system/media，同样由 nginx 处理。
gunicorn 的 worker 数量我是按照“每核 2-3 个 worker”的经验值设置的，4 核机器跑了 8 个 worker。超过 8 个后进程切换开销反而增加，性能并不提升。worker 类型用的同步型 sync，因为主业务没有长连接需求，同步型更稳定，排错也简单。
高并发的测评提交场景，我加了 Redis 缓存来降低数据库压力。测评页面上的量表和题目配置属于高频读取、低频修改的数据，查库一次后存进 Redis，设置 12 小时过期时间。这样几百个学生同时打开测评页面时，数据库不会被打满。
5. 常见问题与排查技巧实录
5.1 测评中途退出导致的数据异常
这个问题在我测试的时候经常出现。学生答了一半就关掉页面，数据库里已经有半条测评记录，但这个记录又不能让预警逻辑识别，因为状态不完整。后来我在AssessmentRecord表里增加了一个status字段，取值in_progress、completed、invalid。中途退出时先把临时答案存下来，但记录状态是in_progress，不计入统计。学生再次进入时优先恢复这个in_progress状态的记录，完成后更新为completed。
这里有个小坑：同一学生反复进入测评，要屏蔽旧的in_progress记录，否则数据库里到处是残书。我的做法是每次创建新记录前先把该学生同一量表下的旧in_progress记录标记为invalid。
5.2 MySQL 连接数被打满
上线后第一次组织全校测评时就遇到这个问题，表现是系统突然卡顿，页面白屏，后台日志报Too many connections。原因也比较典型：gunicorn 的每个 worker 默认会持有自己的数据库连接池，再加上 Flask 报告服务也要连接同一个库，8 个 Django worker + 2 个 Flask worker 在短时高并发下把连接数打爆了。
排查步骤：先用show processlist;看连接状态，发现大量Sleep连接没有释放。解决方案分三层：
- Django settings 里设置
CONN_MAX_AGE = 60做连接复用，不每次请求都新建连接; - MySQL 侧把
max_connections从默认的 151 调高到 500； - 给 gunicorn 加上
--timeout 60，防止慢请求长时间占用连接。
改动后再次压测，连接数稳定在 80 左右，问题解决。
5.3 时间显示错乱
初期没有注意 Django 的TIME_ZONE设置，默认是 UTC，导致学生提交测评记录的时间比北京时间慢了 8 小时。预约时段全部错位，心理老师看到的预约时间跟学生端不一样，直接导致一次咨询放鸽子。排查起来其实很简单，打开一条记录看created_at字段，发现全是 UTC 时间。
解决方法是统一全局时区：TIME_ZONE = 'Asia/Shanghai'，USE_TZ = False，让数据库和 Django 全部使用北京时间。对单机部署的校园项目来说，这个配置最简单最直观。如果将来要扩展成多服务器分布式部署，才需要考虑统一存储 UTC、展示层转换时区的方案。
5.4 量表配置错误导致评分异常
一次给某个年级做测试时，部分学生的测评结果出现了负分，明显逻辑错误。排查发现是某个量表的配置里把反向计分题的范围写错了，导致部分正常计分的题被反转计算。这个 bug 很隐蔽，因为答题人如果全部选中间项，是否反转影响不大；只有选了方向性答案时分数才异常。
这个问题给我们的教训是：量表的评分规则必须至少有两个人交叉验证。我一个人配置完后，找另一位懂心理测评的同事拿着一份已发布的标准答案逐题核对，确认无误后才上线。另外我还在后台加了一个“试算器”功能，心理老师可以输入一组模拟答案，系统实时算出得分和等级，方便验证配置正确性。
5.5 导出报告时的超时问题
Flask 导出 PDF 时如果报告包含大量图表，生成时间可能超过 30 秒，前端请求会超时。虽然我用的 nginx 的 proxy_read_timeout 默认值足够长，但 Ajax 请求在前端的超时时间也要调整，同时给报告生成加上异步处理机制。现在实现是：用户点击导出后，系统先在后台启动一个任务在 Redis 里记录进度，前端轮询查询进度，任务完成后再下载。用户体感变成“提交任务 → 显示进度条 → 下载完成”，虽然不如直接下载快，但稳定可靠，不再出现超时白屏。
6. 隐私安全与合规注意事项
6.1 数据脱敏与分级管理
心理健康系统的数据安全是底线问题。我把学生数据分成三个层级：
- A 层（公开数据）：姓名、班级、学号，用于日常管理的基础信息。
- B 层（受控数据）：测评等级、预警状态，仅对直接相关的教育工作人员可见。
- C 层（敏感数据）：完整测评答卷、咨询访谈记录、家庭背景信息，仅限心理老师和授权管理者可见。
这个分级在系统里通过字段和接口双层控制。字段级控制在数据库层面做：敏感字段单独存表，在 Django Model 中用代理模型或序列化时自动过滤。接口级控制就是前面提到的权限 Mixin 和查询集过滤。
6.2 日志与操作留痕
心理老师修改测评记录、导出报告、查看敏感档案，这些操作都应该记录日志。Django 的信号机制可以监听 Model 的 save、delete 事件，我在关键表上挂了 AuditLog 信号，记录操作人、操作时间、操作类型、变更前后值。一旦出现数据外泄纠纷，可以追溯到具体操作。
日志记录同样要注意隐私。审计日志里的字段信息不能包含完整的测评答案，只记录记录 ID 和变更摘要，避免日志文件本身成为新的泄露点。
6.3 账号安全与密码策略
校园场景下学生账号被盗导致心理数据泄露的风险不可忽视。我做了三个措施：
- 密码最低强度校验，学生账号首次登录强制修改密码；
- 登录失败五次锁定账号 15 分钟，防止暴力破解；
- 学生账号密码采用更简单的规则（因为学生容易忘记），但心理老师和管理员账号强制启用强密码策略。
7. 结语与经验沉淀
这套校园学生心理健康系统从需求梳理到上线大约用了 10 周时间，投入的人力就是两个人：我负责全部开发和部署，一位心理老师全程配合做业务验证。这个配置对于一所普通中学来说，性价比已经非常理想。
我个人实际做下来最大的体会是：心理系统的难点不在技术，而在业务建模的细致程度。同样是预约功能，心理咨询预约和普通课程预约的差异很大；同样是测评功能，心理量表的评分逻辑和考试试卷的批改逻辑完全两码事。技术选型只要确定了 Django 这个基本盘，剩下的事情其实都在“吃透业务”上面。
最后再分享一个小技巧：像这类系统的验收，不要只看功能跑通一个 happy path。建议准备一批模拟学生数据，把测评、预警、预约、报告导出一整条链路反复跑几遍，特别关注异常分支（学生中途退出、量表配置错误、并发冲高、时间跨月跨年）。这些边缘场景才是校园心理系统最容易翻车的地方，提前踩过坑，上线后才能真正睡得着觉。
