1. 项目背景：校园心理健康的真实现状与系统切入点
先说一个我在走访交流中反复听到的痛点：很多学校的心理辅导工作其实不缺热情，缺的是工具。心理老师靠纸质问卷、Excel表格记录学生测评结果，咨询预约靠QQ消息或者口头约定，危机筛查靠班主任“感觉不对劲”再上报。这种模式在一两百人的小规模还好，一旦到了上千人甚至几千人的规模，问题立刻暴露：数据散落、跟进滞后、漏报率高、家长沟通没有留痕。
所以“校园学生心理健康系统”这类项目几乎成了近两年的高频需求。它的本质不是做一个花哨的网站，而是把心理测评、咨询预约、危机预警、档案管理、家校沟通这些环节串成一条可追踪的闭环。技术栈落到Python生态，Django和Flask都是成熟选择，关键是结合校园场景做取舍。
这篇博文，我和大家完整复盘一套可用方案的落地全过程，包括需求拆解、技术选型、核心模块设计、实操代码、常见坑点。无论你是要交毕业设计，还是学校真打算上线一套内部系统，都可以直接参考这套思路。
2. 需求分析与功能规划：先把“要做什么”彻底理清楚
2.1 校园场景的特殊性决定了功能边界
校园心理健康系统和普通的企业管理系统有很大差异。它的用户角色天然分成四类：学生、心理老师/辅导员、班主任、校级管理员（通常是德育处或心理中心负责人）。每一类角色的使用频率和权限边界完全不同。
学生端要的是低门槛和安全感。测评量表填写要简洁，一次登录就能完成，不需要反复输入个人信息；咨询预约要能看见时间空档，最好还能匿名提问。心理老师端要的是效率和预警能力，能批量查看测评结果、自动识别高风险学生、记录干预过程。班主任端则更轻量，主要是查看本班学生的测评完成情况、接收预警提醒、填写日常观察反馈。校级管理员则关注整体数据报表、危机事件统计、各年级趋势对比。
这些角色如果没在需求阶段理清，开发过程中大概率会反复改表结构、改权限逻辑。我见过不少项目，做着做着变成“所有人都能看所有数据”，这种系统在真实校园环境里根本推不下去，因为心理数据比成绩数据更敏感。
2.2 功能模块的优先级怎么排
按实际落地的紧迫程度，我建议把功能拆成三个优先级批次：
P0模块（第一版必须完成）：学生基本信息管理、心理测评量表管理（至少支持SCL-90、SDS这类常用量表）、测评任务发布与填写、测评结果自动计分与分级、高风险学生预警列表、咨询预约与排班管理、基础角色权限体系。
P1模块（第二版迭代）：危机干预记录与跟进台账、班主任观察反馈、匿名倾诉留言板、测评报告导出（PDF/Excel）、数据看板（按年级、性别、时间维度）。
P2模块（后续扩展）：家校沟通记录、API对接校园统一身份认证、消息通知（短信/邮件）、AI辅助心理问答（可选）。
这里有一个很重要的原则：P0必须跑通全流程闭环。很多同类项目失败的原因不是功能不够多，而是连“发布测评任务——学生完成——老师看到分级结果——对高危学生进行干预记录”这条主线都没走通就急着加花哨功能。
2.3 数据敏感性与合规设计
心理健康数据属于高度敏感个人信息。在系统设计阶段就要把合规问题前置。具体落地层面至少要做好这几件事：测评数据与基本信息分库存储，通过用户ID关联而非冗余存姓名；所有涉及测评结果、咨询记录的接口必须做权限校验，前端隐藏不等于安全；操作日志必须记录，谁在什么时间查看了哪个学生的测评报告，要能追溯；面向学生端的页面不展示“心理问题”“精神障碍”等标签化词汇，统一用“测评结果”“建议关注”等中性表述。
这些设计不仅是负责任，也会直接影响到系统能不能真正部署到学校环境。我后面讲数据库设计时会再展开。
3. 技术选型：Django还是Flask，不要凭感觉拍板
3.1 两种框架的核心差异
这是所有用Python做Web项目的人都会纠结的问题。直接说结论：在这个场景下，我首选Django。理由不是Flask不行，而是Django的“全家桶”特性刚好匹配校园管理系统的需求结构。
Django自带Admin后台、ORM、认证系统、表单处理、中间件机制，这些对管理类系统几乎是量身定做。一个测评系统里，心理老师需要维护量表题库、查看测评记录、管理预约时段，如果用Flask，这些全都要自己写CRUD和后台页面，工作量大且容易出安全漏洞。Django的Admin可以快速撑起内部管理界面，自定义权限也方便。
Flask的优势在于灵活和轻量。如果项目只是做一个简单的匿名倾诉页面上线，或者本身已经有一套后端系统、只需要用Flask写个轻量服务做接口聚合，那Flask更合适。但“校园学生心理健康系统”显然是一个需要长期迭代、多角色使用的完整业务系统，Django的项目结构、迁移机制、生态成熟度都更稳。
配置方面，Django默认的settings.py包含INSTALLED_APPS、MIDDLEWARE、DATABASES等结构，开箱即用，建表、迁移、Admin注册一条龙。Flask则需要手动组织blueprint、扩展（Flask-SQLAlchemy、Flask-Login等），这些扩展之间的兼容性偶尔需要调试。对于毕业设计或者学校项目来说，稳定压倒一切。
3.2 数据库与缓存选型
数据库我推荐MySQL或PostgreSQL。如果学校已有数据库运维经验，PostgreSQL在JSON字段处理、数据完整性方面更有优势；如果只是要求简单易维护，MySQL 8.x也是稳妥选择。SQLite只适合本地演示，多人并发写会有锁问题，不建议在真实部署中使用。
缓存服务Redis不是必须，但如果要做消息通知、在线状态管理、或者避免测评报告频繁查库，Redis值得引入。我的建议是：如果项目是毕业设计，先把核心业务跑通，Redis可以后续再加；如果是真实部署项目，消息推送和历史数据归档会需要它。
部署方案上，生产环境推荐Gunicorn + Nginx + Supervisor的组合。Windows机器上开发没问题，但最终部署目标系统为了稳定性和安全性，建议用Linux（如Ubuntu 20.04 LTS）+ Python 3.9+。
3.3 前端方案选择
这个项目不太建议前后端彻底分离。除非你有专门的前端同学配合，否则Django模板 + Bootstrap + 少量Vue/原生JS是最务实的路线。原因很简单：校园系统的大部分页面是表格、表单、详情页，Django模板渲染可以直接复用后端数据，省掉一套API联调的工作量。
如果需要做数据看板，可以在局部页面引入ECharts或Chart.js，通过Django视图返回JSON数据，前端用fetch或axios渲染图表。这样既能满足可视化需求，又不至于把项目升级成前后端分离架构导致部署复杂度翻倍。我后面给的示例代码会按照这个思路来。
4. 核心模块设计与实现：从建表到功能闭环
4.1 数据库模型设计的关键决策
直接上一份简化但完整的数据模型，这是整个系统的基础。先定义用户模型，使用Django自带的AbstractUser扩展字段；再定义学生档案、量表、测评任务、测评记录、咨询预约、干预记录等核心表。
from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): ROLE_CHOICES = ( ('student', '学生'), ('teacher', '心理老师'), ('headteacher', '班主任'), ('admin', '管理员'), ) role = models.CharField(max_length=20, choices=ROLE_CHOICES, default='student') real_name = models.CharField(max_length=50, verbose_name='姓名') student_no = models.CharField(max_length=20, blank=True, null=True, verbose_name='学号') grade = models.CharField(max_length=20, blank=True, null=True, verbose_name='年级') clazz = models.CharField(max_length=20, blank=True, null=True, verbose_name='班级') phone = models.CharField(max_length=20, blank=True, null=True, verbose_name='联系电话')然后定义测评相关的模型。这里有个容易忽略的设计细节：量表题目需要和量表本身分开存表，方便未来增加新量表；测评记录要区分“已提交”和“草稿”状态，防止学生中途退出导致数据半截入库。
class Scale(models.Model): name = models.CharField(max_length=100, verbose_name='量表名称') description = models.TextField(blank=True, verbose_name='量表说明') max_score = models.FloatField(verbose_name='总分上限') level_json = models.JSONField(default=dict, verbose_name='分级规则(如各分数段标签)') created_at = models.DateTimeField(auto_now_add=True) class ScaleQuestion(models.Model): scale = models.ForeignKey(Scale, on_delete=models.CASCADE, related_name='questions') question_text = models.CharField(max_length=500, verbose_name='题目内容') score = models.FloatField(default=1, verbose_name='计分值') sort_order = models.IntegerField(default=0, verbose_name='排序') class AssessmentTask(models.Model): title = models.CharField(max_length=100, verbose_name='任务名称') scale = models.ForeignKey(Scale, on_delete=models.PROTECT, verbose_name='关联量表') target_grades = models.JSONField(default=list, verbose_name='目标年级列表') start_time = models.DateTimeField(verbose_name='开始时间') end_time = models.DateTimeField(verbose_name='结束时间') created_by = models.ForeignKey(User, on_delete=models.PROTECT, verbose_name='创建人') status = models.CharField(max_length=20, default='draft', verbose_name='状态') class AssessmentRecord(models.Model): task = models.ForeignKey(AssessmentTask, on_delete=models.CASCADE, verbose_name='所属任务') student = models.ForeignKey(User, on_delete=models.CASCADE, related_name='assessment_records', verbose_name='学生') answers = models.JSONField(default=dict, verbose_name='答题明细') total_score = models.FloatField(null=True, blank=True, verbose_name='总分') level = models.CharField(max_length=20, blank=True, verbose_name='分级结果') submitted_at = models.DateTimeField(null=True, blank=True, verbose_name='提交时间') is_finished = models.BooleanField(default=False, verbose_name='是否已完成')这里的关键设计点有三个：JSONField在Django中可以直接存字典，用来保存测评答案和量表分级规则，减少很多关联表的复杂操作；题目单独建表，未来新增量表时不需要改代码逻辑；测评记录表通过唯一约束可以防止同一学生对同一任务重复提交，在后续视图中再通过get_or_create控制流程。
4.2 测评流程的实现思路
测评流程是整个系统的核心业务链。一个标准流程是：管理员创建量表并配置分级规则，发布测评任务给指定年级；学生登录后看到待完成的任务，逐题作答；提交后系统根据总分自动分级，覆盖到“低风险—关注—较高风险—高风险”四个等级；心理老师端实时看到分级结果，并能按风险等级筛选。
分级规则我建议放在量表配置里而不是写死在代码里。比如SCL-90的分级阈值、SDS抑郁自评量表的标准分转换方法，不同量表不同规则，甚至同一量表在不同学校的标准也可能有差异。用JSON配置后，心理老师自己就能在后台调整。
def calculate_level(scale, total_score): level_json = scale.level_json levels = sorted(level_json.items(), key=lambda x: x[1]['min']) for name, rule in levels: if rule['min'] <= total_score <= rule['max']: return name return 'unknown'这个函数的逻辑很简单：遍历量表配置的每个等级区间，匹配总分落在哪个区间，返回对应的等级名称。实际项目中，SCL-90这种量表还需要根据选项权重折算分数，逻辑会复杂一些，但整体架构是一致的。
4.3 咨询预约模块的设计要点
咨询预约的难点在于资源冲突和状态管理。每位心理老师可以设置每周可预约时段（比如每周一、三下午第7、8节），学生选择时段后生成预约记录，老师可以在后台确认或改期。预约记录至少需要以下状态：待确认、已确认、已完成、已取消、爽约（未到）、改期。
数据库层面，我设计了一张Appointment表和一张ScheduleRule表。ScheduleRule存储老师的可预约规则，Appointment存储实际的预约记录。校验冲突时，通过过滤同老师、同时段、状态为待确认或已确认的记录数量来判断：
class ScheduleRule(models.Model): teacher = models.ForeignKey(User, on_delete=models.CASCADE, related_name='schedule_rules') weekday = models.IntegerField(verbose_name='星期几(0-6)') start_time = models.TimeField(verbose_name='开始时间') end_time = models.TimeField(verbose_name='结束时间') max_count = models.IntegerField(default=1, verbose_name='该时段最大预约数') is_active = models.BooleanField(default=True) class Appointment(models.Model): STATUS_CHOICES = ( ('pending', '待确认'), ('confirmed', '已确认'), ('completed', '已完成'), ('canceled', '已取消'), ('missed', '爽约'), ('rescheduled', '已改期'), ) student = models.ForeignKey(User, on_delete=models.CASCADE, related_name='appointments', verbose_name='学生') teacher = models.ForeignKey(User, on_delete=models.CASCADE, related_name='teacher_appointments', verbose_name='心理老师') rule = models.ForeignKey(ScheduleRule, on_delete=models.PROTECT, verbose_name='所属时段规则') date = models.DateField(verbose_name='预约日期') start_time = models.TimeField(verbose_name='开始时间') end_time = models.TimeField(verbose_name='结束时间') status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='pending', verbose_name='状态') note = models.TextField(blank=True, verbose_name='学生备注') created_at = models.DateTimeField(auto_now_add=True)这种设计的优势在于排班规则和实际预约记录分离，修改下周排班不会影响已生成的预约。预约冲突校验建议放在视图函数里加事务锁处理，防止两个学生同时提交同一时段的预约出现脏数据。
4.4 预警与干预记录：闭环的关键所在
测评做完了如果不跟进，系统价值就少了一大半。预警功能包含两个层面：测评结果自动预警，比如SCL-90总分超过160分或任一因子分超过2分则自动进入“重点关注”列表；人工上报预警，班主任或心理老师在日常观察中发现异常，可以主动创建一个干预记录。
class InterventionRecord(models.Model): student = models.ForeignKey(User, on_delete=models.CASCADE, related_name='interventions', verbose_name='学生') reporter = models.ForeignKey(User, on_delete=models.CASCADE, related_name='reported_interventions', verbose_name='上报人') record_type = models.CharField(max_length=20, choices=(('auto', '系统预警'), ('manual', '人工上报')), verbose_name='来源类型') risk_level = models.CharField(max_length=20, verbose_name='风险等级') description = models.TextField(verbose_name='情况描述') action_plan = models.TextField(blank=True, verbose_name='干预方案') follow_up_date = models.DateField(null=True, blank=True, verbose_name='跟进日期') status = models.CharField(max_length=20, default='pending', verbose_name='处理状态') created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True)干预记录需要支持多次跟进。这里我采用了“一条记录、多次跟进”的设计：InterventionRecord只保存初始信息和最新状态，跟进历史单独建一张FollowUpLog表，每次回访、约谈、家长沟通都追加一条日志。这样既能看出完整的干预过程，又不会把主表搞得臃肿。
5. 实操实现：核心代码与关键流程落地
5.1 项目初始化与配置
先要说明，这里我会给出可直接跑的示例流程。前提是你本机已经装好Python 3.9+和MySQL（或SQLite先顶着用）。
# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows环境执行 venv\Scripts\activate # 安装依赖 pip install django==4.2 pip install mysqlclient # 如果MySQL连不上，可以先改用SQLite做开发 pip install django-cors-headers djangorestframework pip install gunicorn==21.2.0 # 生产部署时用然后创建Django项目和应用：
django-admin startproject psych_system cd psych_system python manage.py startapp assessment python manage.py startapp appointment python manage.py startapp intervention python manage.py startapp users建议按业务模块拆分应用，而不是把所有模型堆在一个app里。users管用户，assessment管量表与测评，appointment管预约，intervention管干预记录。这样代码结构清晰，后面扩展也不痛苦。
在settings.py里注册应用，并配置认证模型：
INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'users', 'assessment', 'appointment', 'intervention', ] AUTH_USER_MODEL = 'users.User' DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'psych_system', 'USER': 'psych_user', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', } }如果开发阶段不想折腾MySQL，把ENGINE改成django.db.backends.sqlite3、NAME改成db.sqlite3就能先跑起来。但生产阶段务必切回MySQL或PostgreSQL。
5.2 学生端测评提交接口实现
学生端测评提交的核心逻辑是：获取任务ID和题目列表，学生逐题作答后提交答案字典。视图里需要校验任务是否在有效期内、该学生是否已提交过、答案数量是否完整。下面是一个直接用Django视图函数实现的方案：
from django.shortcuts import get_object_or_404 from django.http import JsonResponse from django.views.decorators.http import require_POST import json from .models import AssessmentTask, AssessmentRecord, Scale @require_POST def submit_assessment(request, task_id): user = request.user if user.role != 'student': return JsonResponse({'code': 403, 'msg': '仅学生可提交测评'}, status=403) task = get_object_or_404(AssessmentTask, pk=task_id) now = timezone.now() if now < task.start_time or now > task.end_time: return JsonResponse({'code': 400, 'msg': '不在测评开放时间内'}, status=400) # 利用get_or_create防止重复提交 record, created = AssessmentRecord.objects.get_or_create( task=task, student=user, defaults={'answers': {}}, ) if not created and record.is_finished: return JsonResponse({'code': 400, 'msg': '你已完成该测评，不可重复提交'}, status=400) try: data = json.loads(request.body) answers = data.get('answers', {}) except Exception: return JsonResponse({'code': 400, 'msg': '请求数据格式错误'}, status=400) scale = task.scale # 根据量表计算总分（不同量表的计分规则不同，这里以简单求和为例） total = 0 for q in scale.questions.all(): ans = answers.get(str(q.id)) if ans is None: return JsonResponse({'code': 400, 'msg': f'题目{q.id}未作答'}, status=400) total += float(ans) * q.score level = calculate_level(scale, total) record.answers = answers record.total_score = total record.level = level record.is_finished = True record.submitted_at = timezone.now() record.save() return JsonResponse({'code': 200, 'msg': '提交成功', 'total_score': total, 'level': level})这里面有两个容易被漏掉的细节。第一个是Transaction问题，实际部署中提交和计分的过程建议包裹在transaction.atomic()里，避免记录创建成功后计分失败导致半成品数据；第二个是答案校验粒度，简单求和的需求可以只校验数量，但涉及反向计分的量表（如SDS部分题目是反向计分），必须校验选项值在合法范围内，防止学生传一个超大的数值刷分。
5.3 心理老师端风险筛选视图
心理老师端需要一张按风险等级筛选的学生列表，并展示每位学生的最近一次测评分数与等级。用Django ORM可以写出高效的查询：
from django.db.models import Max, OuterRef, Subquery from .models import AssessmentRecord def get_risk_students(request, level=None): # 只取每位学生最新一条测评记录 latest_ids = AssessmentRecord.objects.filter( student_id=OuterRef('student_id'), is_finished=True ).order_by('-submitted_at').values('id')[:1] records = AssessmentRecord.objects.filter( id__in=Subquery(latest_ids) ).select_related('student').order_by('-total_score') if level: records = records.filter(level=level) data = [] for r in records: data.append({ 'student_id': r.student.id, 'name': r.student.real_name, 'grade': r.student.grade, 'clazz': r.student.clazz, 'total_score': r.total_score, 'level': r.level, 'submitted_at': r.submitted_at.strftime('%Y-%m-%d %H:%M'), }) return JsonResponse({'code': 200, 'data': data})注意我这里用了OuterRef和Subquery来取“每位学生最新的一条记录”。这是一个很常见的ORMA查询优化手段，避免你先查出所有学生再循环查询每个学生的最后一次测评（N+1问题）。只用两条SQL就能完成整个查询。
5.4 测试数据注入与管理后台
开发过程中，手工造数据非常痛苦。建议写一个专用的管理命令，一键生成测试学生、量表、测评任务和模拟测评记录。这一步能节省大量调试时间。
# management/commands/seed_data.py from django.core.management.base import BaseCommand from users.models import User from assessment.models import Scale, ScaleQuestion, AssessmentTask, AssessmentRecord import random class Command(BaseCommand): help = '生成测试数据' def handle(self, *args, **options): # 创建100个学生 for i in range(1, 101): User.objects.create_user( username=f'student{i}', password='123456', role='student', real_name=f'学生{i}', grade='高一', student_no=f'202400{i}', ) # 创建一个简易量表 scale = Scale.objects.create(name='简易压力自评', description='分数越高压力越大') for j in range(1, 11): ScaleQuestion.objects.create(scale=scale, question_text=f'题目{j}', score=1) # 给每个学生生成一条测评记录 for student in User.objects.filter(role='student'): answers = {str(q.id): random.choice([1, 2, 3, 4]) for q in scale.questions.all()} total = sum(answers.values()) AssessmentRecord.objects.create( task=task, student=student, answers=answers, total_score=total, is_finished=True, submitted_at=now, level='high' if total > 30 else 'low', )配合Django Admin注册后，心理老师可以在后台直接管理量表、查看测评记录。注册代码很简单：
from django.contrib import admin from .models import Scale, AssessmentTask, AssessmentRecord @admin.register(Scale) class ScaleAdmin(admin.ModelAdmin): list_display = ('name', 'max_score', 'created_at') @admin.register(AssessmentTask) class AssessmentTaskAdmin(admin.ModelAdmin): list_display = ('title', 'scale', 'start_time', 'end_time', 'status') @admin.register(AssessmentRecord) class AssessmentRecordAdmin(admin.ModelAdmin): list_display = ('student', 'task', 'total_score', 'level', 'submitted_at') list_filter = ('level', 'task')5.5 看板页面的ECharts集成
给校级管理员看的数据看板，我用最简单的方式集成：Django视图返回JSON，前端用ECharts渲染。示例视图代码如下：
from django.db.models.functions import TruncMonth from django.db.models import Count from .models import AssessmentRecord def dashboard_data(request): # 统计每月测评数量 monthly_data = AssessmentRecord.objects.filter(is_finished=True)\ .annotate(month=TruncMonth('submitted_at'))\ .values('month').annotate(cnt=Count('id')).order_by('month') # 统计各级别人数 level_data = AssessmentRecord.objects.values('level').annotate(cnt=Count('id')) return JsonResponse({ 'monthly': list(monthly_data), 'levels': list(level_data), })对应的前端模板片段：
<div id="levelChart" style="width: 100%; height: 400px;"></div> <script> fetch('/dashboard/data/') .then(resp => resp.json()) .then(data => { const chart = echarts.init(document.getElementById('levelChart')); chart.setOption({ title: { text: '测评结果等级分布' }, xAxis: { type: 'category', data: data.levels.map(item => item.level) }, yAxis: { type: 'value' }, series: [{ type: 'bar', data: data.levels.map(item => item.cnt) }] }); }); </script>这种“局部使用JavaScript渲染图表、整体仍然服务端渲染”的混合模式，是这种项目的最佳平衡点。你不需要搭建Node.js前端工程，也不需要处理跨域问题，却能实现足够好看的数据可视化。
6. 常见问题与排查技巧实录
6.1 用户重复登录与Session冲突
校园机房是公用电脑，很多学生用同一台机器登录不同账号。Django默认的Session机制如果配置不当，前一个学生登录后，后一个学生打开页面可能还看到前一个人的信息。
解决方法是配置会话过期时间和清除机制。在settings.py中加入：
SESSION_EXPIRE_AT_BROWSER_CLOSE = True SESSION_COOKIE_AGE = 60 * 30 # 30分钟无操作自动过期同时在退出登录时调用logout(request)，并在学生端页面增加“退出登录”按钮，确保Session被主动清除。如果还想更保险，可以把Session存储放到Redis并配置合理的超时策略。
6.2 测评高峰期并发提交导致的重复记录
全校统一发布测评任务后，几百名学生同时提交，get_or_create本身可以防大部分重复问题，但并发极端情况下可能出现唯一约束冲突。解决办法是在数据库层面加约束，同时配合事务：
class Meta: constraints = [ models.UniqueConstraint( fields=['task', 'student'], name='unique_assessment_per_task_student' ) ]并在视图中把提交逻辑包进transaction.atomic()。出现IntegrityError时捕获并给用户提示“请勿重复提交”。
6.3 心理老师后台管理权限过大
Django Admin默认对所有注册模型开放增删改查，但并不是每个心理老师都需要删除量表或修改题目。建议在Admin中只给心理老师“查看”权限，增加和删除权限仅保留给管理员。
class ScaleAdmin(admin.ModelAdmin): def has_add_permission(self, request): return request.user.role == 'admin' def has_delete_permission(self, request, obj=None): return request.user.role == 'admin'这里要留意，Django Admin的权限判断方法名叫has_*_permission，它会直接决定页面上是否显示对应按钮，以及后端请求是否会成功。这是很多初学开发者会漏掉的一层防线。
6.4 部署后静态文件404
Django部署到生产环境最常见的坑就是静态文件找不到。原因是没有运行collectstatic，或者Nginx没有把静态文件请求转发到正确目录。部署时确保执行：
python manage.py collectstatic --noinput然后在Nginx配置中加一个location块指向STATIC_ROOT：
location /static/ { alias /var/www/psych_system/static/; }这个问题本身不难，但每年都能见到大量项目栽在这里。我的建议是上线前先本地模拟DEBUG=False跑一遍，把所有静态文件问题提前暴露。
7. 部署与性能优化的几点经验
7.1 生产环境部署架构
一个稳定、可维护的部署方案如下：Nginx负责反向代理和静态文件服务，Gunicorn充当WSGI服务器运行Django应用，Supervisor守护Gunicorn进程，MySQL或PostgreSQL存储业务数据，Redis负责缓存和Session存储。这套组合足够支撑一所几千人规模学校的正常并发。
Gunicorn的启动配置示例：
gunicorn psych_system.wsgi:application \ --workers 3 \ --bind 127.0.0.1:8001 \ --timeout 120 \ --access-logfile /var/log/psych_system/gunicorn_access.log \ --error-logfile /var/log/psych_system/gunicorn_error.logworkers数量一般根据CPU核心数调整，公式大致是2*CPU核数+1，但校园系统日常并发不高，跑3到4个worker完全够用。注意timeout不要设太短，测评提交和报表导出在部分配置下可能超过30秒。
7.2 性能优化的几个简单手段
第一，ORM查询用select_related和prefetch_related，避免循环查询。第二，高频读取的数据（如量表列表、排班规则）可以缓存到Redis，设置5到10分钟过期。第三，测评结果的分页查询不要用深offset，改用基于id或时间戳的分页方案。
例如分页时用created_at或id游标：
records = AssessmentRecord.objects.filter(id__lt=last_id, is_finished=True)\ .order_by('-id')[:20]这样即使数据量涨到几万条，分页查询速度也不会明显下降。而传统的page=10000这种深分页会让数据库扫描大量无效行。
7.3 数据备份与恢复策略
心理数据的价值极高，备份必须自动化。简单方案是写一个shell脚本，每天凌晨通过crontab执行mysqldump并备份到异地目录。如果你的学校服务器有对象存储或NAS，建议再同步一份到外部存储。
#!/bin/bash BACKUP_DIR=/data/backups/psych_system DATE=$(date +%Y%m%d%H%M) mysqldump -u psych_user -pYourPass psych_system > $BACKUP_DIR/psych_$DATE.sql find $BACKUP_DIR -type f -mtime +30 -name "*.sql" -delete恢复演练建议每季度做一次，避免真出事时发现备份文件损坏或者恢复流程错误。这个建议不是技术问题，是运维习惯问题，但非常值得坚持。
8. 总结一点我的实践心得
做这个项目时最深刻的体会是：心理健康系统的复杂度不在技术，而在业务语义的理解。测评分数怎么解读、风险等级怎么设定、干预流程怎么留痕，这些都需要和心理老师反复确认。技术只是把业务规则落地的手段。
最后分享一个配置方面的建议：把测评量表的计分规则和分级阈值全部做成后台可配置项。因为不同学校使用的量表版本可能不同，同一量表的常模也会更新，一旦写死在代码里，以后每次调整都要重新发布版本。在项目初期就做成配置化，后边的维护成本会明显下降。这也是我把level_json设计成JSONField存入量表模型的原因。
如果你正准备动手做类似系统，建议第一步不是写代码，而是找一位真实的心理老师聊一小时，理清他们的工作流程。搞清楚了流程，代码只是时间问题。
