企业官网建设流程全解析

高校老师每年最头疼的事情之一，就是期末或者年终考核时整理那一堆教学档案。教案、大纲、成绩单、评教结果、工作量统计散落各处，交材料全靠手工拼凑。我之前帮一个教研室做过一个教师教学档案管理系统，把整个流程从“翻文件夹”变成了“点几下鼠标”，用的就是Python生态里的Web框架。这个项目本身不算复杂，但覆盖了Web开发从数据库设计、后端接口到文件上传管理的一整套完整流程，非常适合拿来练手和落地。

这篇文章就以“django-flask基于python的高校教师教学档案管理系统”为主线，把项目的需求拆解、技术选型、核心实现和那些文档里不会写的坑，完整梳理一遍。无论你是打算交课程设计，还是确实要给学院做一套内部工具，这套思路都能直接参考。我会把Django和Flask的取舍逻辑说清楚，也会把Django实现过程中的关键代码和配置一步步展开，包括数据模型、用户权限、文件上传这些避不开的环节。整个项目跑通之后，你会发现自己对Python Web开发的理解会上一个台阶。

1. 项目全景拆解：这个系统到底要解决什么问题

很多初学者拿到“教师教学档案管理系统”这类题目，第一反应就是：建几个表，写几个增删改查。这种思路不能说错，但做出来的东西大概率只是“能跑”，离“能用”还有很大距离。所以在动手写代码之前，咱们先把这个项目的真实需求盘清楚。

1.1 核心需求解析：纸质档案和本地文件夹的三大痛点

高校教师的教学档案管理，说难听点，很多学校还在用最原始的方式。我见过有的学院，每位老师一个牛皮纸袋，教案、大纲、听课本、成绩单全塞在里面，期末检查时找一份两年前的试卷分析能翻半小时。这种模式至少有三个绕不开的痛点。

第一是分散。材料散落在不同地方，教务科存一份、教研室存一份、教师自己电脑上还有一份。版本稍微不一致，年底对不上账就是灾难。第二是统计效率极低。学院要报一个“本年度副教授以上教师人均课时数”，需要人事科、教务科、各教研室来回跑，人工汇总小一周。第三是检索困难。想查某位老师近三年的评教趋势，没有系统的话只能翻纸质记录，几乎不可能做到。

这个项目要解决的，就是上面三个问题。系统需要把教师的基本信息、授课记录、教学工作量、评教结果、科研情况、教学成果、档案附件统一管起来，让老师自己在线上传材料、维护数据，教务处可以导出统计报表，学院领导能按权限查看，形成一套完整的数字档案闭环。

1.2 功能模块边界：哪些不能少，哪些先不做

在做技术选型之前，先确定功能边界。一个“能用不冗余”的老师教学档案管理系统，这几个模块建议优先做。

有一种常见误区是功能越全越好，上来就搞“复杂审批流、角色工作台、消息通知”。如果你是做实际交付，先冷静一下。内部管理工具的核心价值是“收集数据 + 检索 + 简单统计”，那些花哨流程反而会增加使用成本。等到系统跑起来，老师习惯了在线填表，再考虑扩展才是正路。

1.3 技术选型的前思后量：Django和Flask到底怎么选

标题里写了“django-flask基于python”，这是很多人拿不准的点。我的建议很简单直接：正式开发选Django，Flask适合原型验证和快速演示。

这样选不是没有原因的。Django自带的Admin后台，对管理系统来说是巨大的生产力工具。教师档案这种典型的数据录入场景，Django Admin几乎不用写前端就能直接满足内部使用的需求，自带的ORM、认证授权、表单校验、分页、Admin界面，全是这套系统用得上的东西。Flask虽然灵活，但用户认证要自己配Flask-Login，ORM要自己选SQLAlchemy，Admin后台要装Flask-Admin，前后端都要额外折腾，好处是轻量，坏处是“什么都要自己组装”。

有一种声音说Flask更简单，实际上Flask的简单体现在框架本身，不在业务落地。做管理系统，Django用半小时能搭出来的后台，Flask可能要折腾小半天。至于真正的前后端分离大项目，那是Vue/React加DRF的场景，跟这个项目场景并不完全匹配。

另外说一句Pycharm和VSCode的选择，如果你刚入门，用Pycharm社区版配上Django插件，跑项目最省心。环境配置永远是小事，技术方案确认了再谈环境才不会做无用功。

2. 数据库设计：档案管理系统的地基怎么打

系统能不能好用，数据模型的设计至少占了一半功劳。很多人的项目做到一半推倒重来，基本都是栽在表结构设计上。教学档案系统里核心表就那么几张，但关系和字段设计是有讲究的。

2.1 核心表结构与字段设计思路

围绕教师档案管理，核心模型我设计了下面这几个：

# models.py 核心表设计 from django.db import models from django.contrib.auth.models import User class Department(models.Model): name = models.CharField('院系名称', max_length=100) code = models.CharField('院系代码', max_length=20, unique=True) class TeacherProfile(models.Model): STATUS_CHOICES = ( ('active', '在编'), ('retired', '退休'), ('left', '调离'), ) TITLE_CHOICES = ( ('assistant', '助教'), ('lecturer', '讲师'), ('associate', '副教授'), ('professor', '教授'), ) user = models.OneToOneField(User, on_delete=models.CASCADE, verbose_name='关联账号') department = models.ForeignKey(Department, on_delete=models.PROTECT, verbose_name='所属院系') employee_no = models.CharField('工号', max_length=20, unique=True) name = models.CharField('姓名', max_length=50) title = models.CharField('职称', max_length=20, choices=TITLE_CHOICES) status = models.CharField('档案状态', max_length=20, choices=STATUS_CHOICES, default='active') hire_date = models.DateField('入职时间', null=True, blank=True) education = models.CharField('最高学历', max_length=50, blank=True) phone = models.CharField('联系电话', max_length=20, blank=True) created_at = models.DateTimeField('创建时间', auto_now_add=True) updated_at = models.DateTimeField('更新时间', auto_now=True) class CourseRecord(models.Model): teacher = models.ForeignKey(TeacherProfile, on_delete=models.CASCADE, verbose_name='教师') semester = models.CharField('学期', max_length=20) # 2023-2024-1 course_name = models.CharField('课程名称', max_length=100) course_code = models.CharField('课程代码', max_length=20, blank=True) course_type = models.CharField('课程性质', max_length=20) # 必修、选修、公共课 weekly_hours = models.DecimalField('周学时', max_digits=4, decimal_places=1) total_hours = models.DecimalField('总学时', max_digits=5, decimal_places=1) student_number = models.IntegerField('选课人数', default=0) credit = models.DecimalField('学分', max_digits=3, decimal_places=1) class TeachingEvaluation(models.Model): course_record = models.ForeignKey(CourseRecord, on_delete=models.CASCADE, verbose_name='关联课程') score = models.DecimalField('评教分数', max_digits=4, decimal_places=1) evaluation_time = models.DateField('评教时间') comments = models.TextField('评教意见', blank=True) class ResearchOutput(models.Model): OUTPUT_TYPE = ( ('paper', '论文'), ('project', '课题'), ('book', '教材'), ('award', '获奖'), ) teacher = models.ForeignKey(TeacherProfile, on_delete=models.CASCADE, verbose_name='教师') output_type = models.CharField('成果类型', max_length=20, choices=OUTPUT_TYPE) title = models.CharField('成果名称', max_length=200) journal = models.CharField('发表期刊/课题来源', max_length=200, blank=True) date = models.DateField('日期') level = models.CharField('级别', max_length=50, blank=True) class ArchiveFile(models.Model): teacher = models.ForeignKey(TeacherProfile, on_delete=models.CASCADE, verbose_name='教师', related_name='files') file_name = models.CharField('文件名称', max_length=200) file_type = models.CharField('文件类型', max_length=50) file = models.FileField(upload_to='archive_files/%Y/%m/') uploaded_at = models.DateTimeField('上传时间', auto_now_add=True)

这套设计有几个关键细节值得展开说说。

用户与档案一对一关联。这个设计很关键。直接用Django内置的User表做登录，再通过OneToOneField扩展出教师档案信息，而不是修改原生User表。好处是什么呢？登录认证、密码管理、权限分组这些都是Django现成的，我们只扩展不加改动。教学秘书和院系管理员可以没有TeacherProfile，但每位老师都有独立账号。

外键删除保护策略。在院系和教师的关系上，我用的是on_delete=models.PROTECT，不是默认的CASCADE。你想想，如果某个院系不小心被删了，级联删除会直接把该院系下所有老师的档案全干掉，这种操作在生产环境是不可接受的。PROTECT会阻止删除，除非先把关联教师全部移除，这才是内部系统该有的安全底线。

课时和学分用DecimalField不用FloatField。这是容易踩坑的细节。Python的浮点数存在精度问题，0.1加0.2可能等于0.30000000000000004。教务系统里的学时学分会涉及统计报表，一旦浮点误差被放大，年底数据对不上非常尴尬。DecimalField配合max_digits和decimal_places，保证数据库层就是精确小数。

2.2 为什么默认预留文件存储字段而不是另建文件服务

看到ArchiveFile模型有人会问：为什么不直接把FileField放在TeacherProfile里？这是一个经常被忽略的设计问题。

教学档案里，一个老师可能有几十个附件，如果把文件字段直接挂在TeacherProfile上，表里就得留几十个文件字段，或者把所有文件塞进一个字段里。前者又蠢又难扩展，后者完全没法检索分类。单独建一个ArchiveFile表，一个老师对应多条文件记录，每个文件有自己的类型、上传时间、文件名，后续想要按条件筛选文件非常方便。

文件实际存储路径用了upload_to='archive_files/%Y/%m/'，Django会自动按年月建目录。好处是时间一长，服务器上的目录结构本身就是按时间归档的，天然便于备份和清理。注意，生产环境千万别把文件直接放在项目根目录，建议配置独立存储路径，这个后面会细说。

3. 手把手实操：从空项目到核心功能跑通

数据库模型确定之后，剩下的事情就是把项目骨架搭起来、把配置调好、把核心功能逐一实现。这一步我踩过的坑不少，所以单独用一整个章节把完整流程和细节写清楚。

3.1 环境准备与项目骨架搭建

先把基础环境准备好。本地开发建议用虚拟环境，避免不同项目的依赖互相打架。这一步对新手特别值得花时间，磨刀不误砍柴工。

我们直接用命令行操作，先创建虚拟环境并激活，然后安装Django。

# 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # Windows下用 .\venv\Scripts\activate # 安装依赖 pip install django pip install mysqlclient pip install pandas openpyxl # 用于Excel导出 # 查看安装版本，确认环境OK python -m django --version

Django的版本，建议用当前稳定版本，不要追最新，图新很容易遇到第三方兼容问题。

接下来创建项目和应用。一个项目对应一个站点，项目里的app对应业务模块。这个系统我建议拆成两个app：accounts管登录和用户，archives管教师档案核心业务。

# 创建项目和应用 django-admin startproject teacher_archive cd teacher_archive python manage.py startapp accounts python manage.py startapp archives

项目结构大致如下：

teacher_archive/ ├── accounts/ │ ├── views.py # 登录、登录后跳转 │ └── forms.py # 自定义登录表单 ├── archives/ │ ├── models.py # 上面设计的业务模型 │ ├── views.py # 档案增删改查 │ ├── admin.py # 后台管理注册 │ └── forms.py # 表单校验 ├── teacher_archive/ │ ├── settings.py # 全局配置 │ ├── urls.py # 路由入口 │ └── wsgi.py ├── static/ # 静态文件 ├── media/ # 上传文件，生产环境不放在这 ├── templates/ # 模板文件 └── manage.py

然后把app和相关的数据库配置加到settings.py里。开发阶段我用SQLite，部署阶段建议切MySQL，这个后面会讲为什么。

# settings.py INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'accounts', 'archives', ] DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': BASE_DIR / 'db.sqlite3', } }

3.2 Django Admin后台的二次开发：不用写前端也能有极好的操作界面

档案管理系统最让我庆幸的事，就是Django自带的Admin后台足够好用。对内部管理系统来说，Admin不仅是数据管理工具，直接就是整个系统的操作台。把模型注册进去，增删改查页面几乎是免费的。

# archives/admin.py from django.contrib import admin from .models import TeacherProfile, CourseRecord, TeachingEvaluation, ResearchOutput, ArchiveFile @admin.register(TeacherProfile) class TeacherProfileAdmin(admin.ModelAdmin): list_display = ('employee_no', 'name', 'department', 'title', 'status') list_filter = ('department', 'title', 'status') search_fields = ('employee_no', 'name') list_per_page = 20 readonly_fields = ('created_at', 'updated_at') autocomplete_fields = ('user',)

这里有几个提升体验的细节值得专门说。

list_display控制后台列表展示的字段，list_filter显示侧边栏筛选器，按院系、职称、状态筛选是教学秘书最常用的操作。search_fields指定搜索字段，工号和姓名最常见的查询方式。list_per_page避免老师太多时单页列表卡顿。readonly_fields把“创建时间”“更新时间”这种系统生成的字段设为只读，防止误改。

autocomplete_fields是个容易忽略的小技巧，它依赖User模型上的search_fields，在下拉关联用户时支持搜索而不是从几百条记录里翻。前提是UserAdmin里也要配置search_fields，否则会报错。

3.3 普通教师角色的登录流程与权限控制

系统不能让所有老师都直接进Admin后台，那样权限太混乱了。更合理的方案是：普通教师登录后进入一个专门设计的普通用户页面，只维护自己的档案。教学秘书、学院管理员走Admin后台，进行数据汇总和审核。

实现思路是给不同用户分组，用Django自带的Group加权限控制。

# accounts/views.py from django.contrib.auth.decorators import login_required from django.contrib.auth.models import Group @login_required def teacher_dashboard(request): teacher = request.user.teacherprofile active_courses = CourseRecord.objects.filter(teacher=teacher, semester='2024-2025-1') research_list = ResearchOutput.objects.filter(teacher=teacher) return render(request, 'accounts/dashboard.html', { 'teacher': teacher, 'active_courses': active_courses, 'research_list': research_list, })

关键点在request.user.teacherprofile这一行。因为TeacherProfile里用OneToOneField关联了User，Django会自动生成反向关联，所以通过当前登录用户可以直接获取该老师的档案数据，不需要额外查询。这就是一对一关联在真实业务中带来的便利，代码可读性一下子就上去了。

数据库迁移的时候有个重要的坑，扩展内置User模型，一定要在第一次迁移前就设置好，或者用OneToOne扩展，不然上线后很难改。我们这套方案用的是扩展表，不需要动Django的auth_user表，规避了这个大坑。

# archives/forms.py from django import forms from .models import CourseRecord, ResearchOutput, ArchiveFile class CourseRecordForm(forms.ModelForm): class Meta: model = CourseRecord fields = ['semester', 'course_name', 'course_code', 'course_type', 'weekly_hours', 'total_hours', 'student_number', 'credit'] widgets = { 'semester': forms.Select(choices=[ ('2024-2025-1', '2024-2025学年第一学期'), ('2024-2025-2', '2024-2025学年第二学期'), ('2025-2026-1', '2025-2026学年第一学期'), ]), }

表单提交后，视图里需要把当前教师自动填充到课程记录的teacher字段。千万不要让老师自己选择自己是谁，这是安全漏洞，header或者表单里放一个隐藏字段也不够严谨，正确做法是服务端从request.user推导当前教师：

# archives/views.py def add_course(request): if request.method == 'POST': form = CourseRecordForm(request.POST) if form.is_valid(): course = form.save(commit=False) course.teacher = request.user.teacherprofile course.save() return redirect('teacher_dashboard') else: form = CourseRecordForm() return render(request, 'archives/course_form.html', {'form': form})

看到commit=False了吧，这是ModelForm的核心技巧之一。它让模型实例先进入内存但不落库，等我们把teacher字段补上之后再正式保存，完美避免数据被篡改。

3.4 教学档案附件的上传与管理细节

文件上传是教学档案系统另一个避不开的模块。教案、教学大纲、成绩分析报告，都得能传能看能下。Django对文件上传的支持比较完善，但配置不对照样出各种问题。

先在settings里配置好上传路径和允许的类型。

# settings.py MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'uploads' # 限制上传大小，防止大文件撑爆服务器 DATA_UPLOAD_MAX_MEMORY_SIZE = 10485760 # 10MB

然后在项目根urls.py里挂载媒体文件的访问路由。调试阶段这段代码是必须的，否则上传的文件无法通过URL访问：

# teacher_archive/urls.py from django.conf import settings from django.conf.urls.static import static urlpatterns = [ path('admin/', admin.site.urls), path('', include('accounts.urls')), path('archives/', include('archives.urls')), ] if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

视图那边，用ModelForm处理文件字段简直是享受。因为ArchiveFile模型里就是FileField，Django表单会自动处理文件对象。

# archives/forms.py class ArchiveFileForm(forms.ModelForm): class Meta: model = ArchiveFile fields = ['file_name', 'file_type', 'file'] widgets = { 'file_type': forms.Select(choices=[ ('syllabus', '教学大纲'), ('lesson_plan', '教案'), ('paper_analysis', '试卷分析'), ('summary', '教学总结'), ]) }

上传文件有一个坑：Django默认把上传文件放在内存里，文件一大，占的内存就非常可观。所以模型里upload_to用了年月目录，同时建议在视图层做扩展名和文件大小的二次校验。另外，生产环境务必用NGINX这类Web服务器来服务媒体文件目录，Django自带的开发服务器处理并发上传能力非常有限。

还有一个容易被忽视的点：文件删除问题。从数据库里删掉一条ArchiveFile记录，Django默认并不会自动删除物理文件。这样会导致文件系统里积累很多孤儿文件，时间长了很占空间。解决方案是给模型重写delete方法，或者用Django Signal在删除记录时同步删除文件。

# archives/models.py class ArchiveFile(models.Model): # ... 字段省略 def delete(self, *args, **kwargs): self.file.delete(save=False) # 先删物理文件 super().delete(*args, **kwargs) # 再删数据库记录

3.5 工作量统计和Excel导出：让数据变成决策依据

档案系统的最终价值体现在统计和输出上。到了期末，教务处要的“XX老师本学期总课时”“XX院系副教授人均课时”，不能靠人工拿着计算器一个个加。用Django的ORM聚合查询写起来非常清爽，再配合pandas和openpyxl，直接导出Excel报表。

# archives/views.py import pandas as pd from django.db.models import Sum from django.contrib.admin.views.decorators import staff_member_required @staff_member_required def export_workload_excel(request, semester): # 跨表查询，按教师和学期汇总总学时 workloads = (CourseRecord.objects .filter(semester=semester) .values('teacher__employee_no', 'teacher__name', 'teacher__department__name') .annotate(total_hours=Sum('total_hours'), total_students=Sum('student_number')) .order_by('teacher__department__name')) # 转成DataFrame直接输出Excel df = pd.DataFrame(list(workloads), columns=[ '工号', '姓名', '院系', '总学时', '学生总数']) df.columns = ['工号', '姓名', '院系', '总学时', '学生总数'] response = HttpResponse(content_type='application/vnd.openxmlformats-officedocument.spreadsheetml.sheet') response['Content-Disposition'] = f'attachment; filename="workload_{semester}.xlsx"' df.to_excel(response, index=False) return response

这里有个知识点必须讲清楚，就是Content-Disposition。这个响应头告诉浏览器“这是一个需要下载的附件”，attachment会触发下载行为而不是直接在浏览器打开，而不是用默认方式打开。Django里还有一个专门处理文件下载的函数FileResponse，对于大文件下载性能更友好。

关于values配合annotate，这是ORM里的组合拳。values('teacher__name')先行分组，再通过Sum('total_hours')对总学时求和。这种查询方式能有效减少数据库压力，避免把所有记录都加载到Python内存里逐条加总。

4. 部署上线与常见问题排查实录

项目开发完了，下一步就是部署到服务器真正投入使用。这部分出问题的概率相当高，我把实际踩过的坑整理成一个速查表，按优先级从高到低排好。

4.1 MySQL连接与中文乱码：本地没问题，服务器全报错

开发阶段用SQLite很舒服，但生产环境建议换成MySQL。SQLite在高并发写入场景下会锁表，教学秘书和老师同时在线操作的时候容易卡顿。切MySQL后，最常见的一个错误是：

django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module. Did you install mysqlclient?

这个错误在Windows上尤其常见。直接pip install mysqlclient失败，是因为它依赖MySQL的C语言客户端库。Windows解决办法：去下载对应Python版本的mysqlclient离线whl包，然后再pip install。在Linux系统上一般先装依赖：

sudo apt install python3-dev default-libmysqlclient-dev build-essential pip install mysqlclient

连接配置改一下settings即可：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'teacher_archive', 'USER': 'archive_user', 'PASSWORD': 'strong_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', # 关键！必须用utf8mb4 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", }, } }

中文乱码是MySQL里的高频问题。老库默认字符集可能是latin1或utf8，存emoji和特殊符号会报错或者变成乱码。解决办法是建库时明确指定utf8mb4字符集，和Table的collation一致，一劳永逸。另外还要注意，连接串里必须带上charset: utf8mb4，否则即使库表是对的，ORM连接时也可能用错字符集。

4.2 时区诡异问题：为什么时间总差8小时

档案系统里，教师上传附件时记的是“北京时间”，但数据进数据库后发现时间戳变成了UTC时间，差8小时。这个问题几乎每位用Django的人都会遇到一次。

原因在settings里的TIME_ZONE配置。如果你的代码是：

TIME_ZONE = 'UTC' USE_TZ = True

那么所有auto_now_add和auto_now字段都会以UTC时间保存，前端展示时再做时区转换。管理系统内部使用，最简单粗暴的解决方案是：

TIME_ZONE = 'Asia/Shanghai' USE_TZ = False # 关闭时区转换，直接存本地时间

内部工具，不需要全球用户同时访问，USE_TZ = False能省掉很多显示端调整时区的麻烦。但如果你未来要做数据对外开放或者跨时区协作，还是建议USE_TZ = True，显示层做时区转换。

4.3 静态文件和媒体文件的404问题

Admin界面样式全丢了，上传的附件也打不开，原因基本都是static和media的配置问题。

开发环境下，需要保证settings里有：

STATIC_URL = '/static/' STATICFILES_DIRS = [BASE_DIR / 'static'] MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'uploads'

且项目urls.py里已经挂载了media路由。production环境则要执行collectstatic把静态文件收集到一个公共目录，再交给NGINX来处理。总是有人忘记collectstatic这一步，部署完后台样式全裸奔。

4.4 上传大文件超时和权限问题

老师上传一个几十MB的教学视频，结果等了几分钟提示“连接被重置”，这类问题不是Django的锅，往往是Web服务器的限制。NGINX默认允许的body size是1MB，超过就报413。改配置：

client_max_body_size 100m;

同时注意项目里设置的DATA_UPLOAD_MAX_MEMORY_SIZE也要相应调整。另外，服务器上的uploads目录要给运行Nginx或uWSGI的用户写权限，不然表单提交时会出现Permission denied。关于权限问题，稍微展开多说两句。很多Linux部署问题都是权限惹的祸，不只是媒体目录，Django项目里生成的db.sqlite3文件也要确认所属用户是否正确，尤其是以root方式创建的文件，web用户根本写不进去。

4.5 常见问题速查表

把上面的经验整理成一张速查表，方便你直接对照排查。

5. 项目扩展方向：从“能用”到“好用”的升级思路

如果这套系统顺利跑起来，你肯定不满足于现状。后面可以做的扩展其实不少，根据我自己的实践经验，提几个性价比高、容易上手的方向。

数据可视化是性价比最高的扩展。评教结果、工作量这些数据，在Django后台里只有一张表格，如果引入Chart.js或者ECharts，把数据用图表展示出来，整个系统的专业度立刻不一样。具体做法是写一个统计视图，用ORM聚合查询输出JSON，模板里引入图表库渲染。这一块对前端要求不高，照着官方文档来就行。

对接爬虫数据是另一种思路。如果学校有独立的教务系统，每年要人工把评教结果录入档案系统，特别痛苦。可以研究下学校教务系统的登录和成绩查询接口，用爬虫把评教数据自动拉取入库。不过这块最需要谨慎，必须确认爬虫方案在校方允许范围内再动手，别给自己惹麻烦。

从Django Admin扩展到前端页面。Admin的后台毕竟面向内部管理人员，给学院院长看整体数据时，一个独立的数据看板页面更合适。Django模板系统配合Bootstrap，完全可以做出这个页面，不需要前端框架，学习成本低很多。

权限颗粒度细化。当前的权限模型是“老师能看自己、管理员能看全部”。如果院系之间需要隔离，可以在分组基础上追加对象级权限，比如按Department过滤查询集。Django的权限框架基本都能覆盖，这里用好user_passes_test和自定义权限就行。

写在最后：这个项目给我带来的三点体会

这个教学档案管理系统做完，给我最大的收获不是把Django语法练熟了，而是理解了“工具服务于业务”这件事本身的分量。第一次交付给教研室时，老师和教学秘书反馈最多的并不是界面好不好看，而是“导出Excel怎么还没做”“老师能不能自己上传教案”这类看似简单、实际极其影响使用意愿的功能。你以为的重点跟用户实际需要的重点常常不一样，早调研早确认永远是最高效的路线。

再分享一个细节，我后来给系统做了一键备份的脚本，每天凌晨打包数据库和uploads目录。档案数据对老师来说是多年的成果，一旦服务器硬盘故障，损失无法挽回。这个脚本用到的是Python标准库里的shutil加subprocess，几行代码的事，但整个系统的安全等级因此高了一个量级。

如果你正准备照着这个思路动手，我从过来人的角度提一个建议：不要一上来就铺开所有功能，先做最核心的“教师档案 + 课程记录 + 文件上传”三个模块，用起来，听到反馈之后再迭代。这套系统我已经跑了大半年，稳定性和实用性都经住了考验，也让我对Python Web开发的整体链路有了全新的认知。