企业官网建设流程全解析

看到这个标题，懂行的同学应该一下就明白了：这是一条非常典型的毕业设计技术路线——Python + Flask 做后端，微信小程序做前端，再套一个"学业导师制"的管理场景。编号84033202这种命名方式，一看就是某个毕设选题库里的标准编号。

说实话，这个题目的组合很有意思。单独做选课系统、单独做成绩查询，都偏老套了。但加上"导师制"之后，系统的业务逻辑就从单纯的数据CRUD，变成了有角色协作、有评估流程、有师生互动闭环的真实管理系统。这篇文章我就以这个标题为原型，把从需求拆解、技术选型、数据库设计，到核心接口实现、调试排坑的完整过程都捋一遍。不管你最后是照着做，还是想在这个基础上改出自己的毕设项目，这篇文章应该都能帮你省掉不少摸索的时间。

1. 项目整体设计与思路拆解

1.1 导师制到底是什么？先把这个业务模型搞清楚

很多同学看到"学业导师制"这几个字，直接把它理解成"多加一个老师角色，能登录、能查看学生列表"就完事了。这是最大的误区。导师制和普通的教师管理有着本质区别，它背后的业务逻辑是这样的：

• 每个学生入学后被分配一位学业导师（通常为专业教师），导师负责指导学生的学习规划、选课建议、学业预警和成长评估。
• 导师不是课程的任课老师，也不是教务管理员，他是学生整个在校周期的**“学业责任人”**。
• 导师需要能看到学生的历史选课情况、各科成绩、综合评估等级，并且能给出指导记录和反馈意见。
• 选课行为不应该完全放任学生自己操作——理想情况下，学生选课需要经过导师的指导意见，或者至少导师能一览学生当前的选课计划。

有了这层理解，系统的核心模块就清楚了：选课管理模块、成绩评估模块、导师指导模块。三者是有逻辑关系的——学生选课，课程结束后产生成绩，成绩通过一定的规则转换成评估等级，导师基于评估等级给学生写指导记录，学生看到指导记录后调整下一学期的选课计划。这样就形成了一个完整闭环。

如果你在开题报告里把这个闭环画出来，导师的评语基本就稳了。这也是这个题目和普通"学生管理系统"拉开差距的地方。

1.2 功能模块拆解：前台、后台、导师端各管什么

基于上面的业务模型，我把系统拆成三个终端视角：

学生端（微信小程序）

• 注册登录（通常用学号 + 密码，或微信授权快速登录）
• 查看可选课程列表（分学期、分专业、显示余量）
• 一键选课/退课，选课前能看到自己的导师建议（如果有）
• 查看已选课程、成绩单、综合评估结果
• 查看导师的指导记录，能提交学习疑惑，等导师回复

导师端（微信小程序或同一个小程序里切换角色）

• 查看名下学生列表
• 查看某位学生的选课情况和成绩单
• 对学生的成绩评估结果进行"导师评语"
• 发布指导记录/约谈记录

管理后台（Flask 做的 Web 管理页面）

• 学生、教师、导师信息管理（导入、编辑、重置密码）
• 课程管理（开设课程、设定容量、设定学期）
• 导师分配（把学生批量绑定给导师）
• 成绩录入（任课老师录成绩，或者管理员录入）
• 评估规则配置（比如平时分、期末分权重）

有的同学可能会问："小程序里做三个角色切换是不是太复杂了？"我的建议是：管理后台单独做一套Web页面，小程序只做学生端和导师端，管理员在后台操作。这样既省事，也符合真实系统的使用习惯，毕竟没有哪个管理员天天拿手机录成绩。

1.3 核心流程拆解：选课、评估、指导的逻辑顺序

一个完整的业务时序大概是这样的：

1. 管理员在后台开设新学期的课程，设置每门课的容量、学分、任课老师。
2. 学生在小程序里查看课程列表，选课（受容量限制、受选课时间窗口限制）。
3. 选课结束后，任课老师（或管理员）录入成绩。
4. 系统根据评估规则自动计算总分和等级，生成学生的学期评估结果。
5. 导师查看名下学生的评估结果，写指导建议；学生收到通知并查看。
6. 如学生对成绩或指导建议有疑问，可以在小程序内留言，导师回复。

要注意的是，每一步之间是有状态的。比如：学生选了课但老师还没录成绩，评估模块应该显示"待评估"；导师没写指导记录，学生端应该显示"暂无指导"而不是报错。这些状态字段在设计数据库时需要提前规划好。

2. 技术选型解析：为什么是 Flask + 微信小程序 + MySQL？

2.1 为什么选 Flask，而不选 Django 或 SpringBoot？

很多同学在选后端框架时犹豫不决。我的看法很直接：如果是毕设，Flask 是性价比最高的选择。

• 轻量，容易入门，调试方便。Django 是一个大而全的框架，自带 Admin 后台、ORM、表单校验，但它的设计思想需要一定时间去适应，对新手来说反而容易被"框架自动生成的东西"搞糊涂。
• Flask 的路由和视图函数非常直观，写一个接口就是三五行代码的事。对于选课成绩评估这类中小型系统，Flask 完全够用。
• 用 Flask + SQLAlchemy 做 ORM，操作数据库的代码量比纯 SQL 少很多，而且不容易出错。数据库表设计好了之后，写 model 类基本就是复制粘贴的事。
• 资料多。Flask + 小程序的组合是毕设里的"大众款"，遇到问题基本都能搜到现成的解决方案。

至于为什么不选 SpringBoot——不是不能选，但 Java 全家桶的启动配置、依赖管理、环境部署，对很多人来说是个隐形时间黑洞。做毕设的时间就那么多，把时间花在业务实现上比花在环境搭建上划算得多。

2.2 小程序端为什么是微信小程序，而不是纯 H5 或 App？

这个题目限定得很清楚，就是要做微信小程序。这套方案的现实好处是：

• 学生不需要安装 App，微信里扫一扫或搜一搜就能打开，使用门槛低，演示效果直观。
• 小程序有自己的登录体系（wx.login 获取 code，后端换 openid），天然解决了"用户身份识别"问题，不用自己做手机号验证。
• 毕设答辩时，用开发者工具演示 + 手机真机演示都可以，非常方便。

课程和成绩这类数据，其实不太需要很复杂的 UI。小程序原生的 view、scroll-view、表单组件完全够用，不需要引入额外的 UI 组件库。但如果后期想做美观一点的图表（比如成绩趋势图），可以引入 ECharts 的微信小程序版本，不过这点对毕设来说属于加分项，不是必需品。

2.3 数据库选型：MySQL 还是 SQLite？

如果只是本地演示，SQLite 确实更省事，连数据库安装都省了。但毕设有一个隐藏要求是"系统设计要规范"，大多数评委会默认你应该用 MySQL。我更推荐直接上 MySQL，理由有三个：

• 评委会问"你的系统能处理多少并发？"如果答"SQLite 单文件数据库"，这就比较被动了。但如果你说"MySQL + 连接池 + 事务处理选课并发"，对方的印象分会明显不同。
• MySQL 部署在本地或云服务器上都容易，Navicat 或命令行管理数据都很方便，数据导出导入的生态也更成熟。
• 成绩评估系统的数据模型天然带关联关系（学生↔课程↔成绩↔导师），MySQL 的外键约束和事务机制能帮你省掉很多逻辑判断。

数据库连接建议用 PyMySQL，配合 SQLAlchemy 的 ORM 一起用。连接串大致是这样：

SQLALCHEMY_DATABASE_URI = 'mysql+pymysql://root:your_password@localhost:3306/student_system?charset=utf8mb4'

别小看这个charset=utf8mb4，如果你漏掉它，存个中文备注就有可能出现乱码，这是个特别经典的坑。

3. 数据库设计与核心表结构

3.1 表结构设计：八张表怎么组织最合理

做这种管理系统，数据库表设计直接决定后续代码的复杂程度。我不建议一上来就直接建表，先用一张纸把实体和关系画清楚。这个项目我需要建议的核心表如下：

这里我重点解释几个容易被忽视的设计细节。

3.2 选课表为什么要同时承载成绩字段？

有的同学会把"选课表"和"成绩表"分成两张表，逻辑上没什么问题，但实际写代码时你会发现要反复 JOIN，麻烦不说，还容易出现状态不同步的情况。

更合理的做法是把成绩字段直接挂在选课记录上：学生选了一门课，student_course 表里就多一条记录，status 是"已选"。老师录完成绩后，update 这条记录的 regular_score、exam_score、total_score、grade_level 字段，status 改成"已结课"。一条记录走完一个完整生命周期，查询成绩单的时候直接从这张表里过滤 status='已结课' 就行，少写很多关联代码。

selected_count这个字段是课程表上的“已选人数”，它和 student_course 表里 status='已选' 的记录数要保持一致。选课时判断selected_count < capacity是防止超选的第一道关卡。

3.3 导师绑定表为什么需要单独建一张表？

很多人会直接在 student 表上加一个 tutor_id 字段，这样也能表示"某个学生的导师是谁"。但为什么我建议单独建 tutor_student 表？

因为导师和学生的关系是可以变动的。比如大二重新分导师、有老师离职转岗，如果直接改 student 表，历史关联就丢了。更重要的是，单独建表可以记录绑定时间、绑定状态，后续还可以做"换导师申请"这个功能点。哪怕毕设时不做换导师，有这个表在，系统结构上也更规范。

此外，guidance_record 表建议加上type字段，用来区分"导师主动约谈"和"学生发起提问"，这样后续做消息通知时更容易扩展。

3.4 一段可以直接抄的建表 SQL

下面是我认为比较完整的核心表建表 SQL（节选关键几张表）：

CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender VARCHAR(4) DEFAULT '男', grade VARCHAR(10) COMMENT '年级，如2024级', major VARCHAR(50) COMMENT '专业', password_hash VARCHAR(200) NOT NULL, phone VARCHAR(20), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(100) NOT NULL, credit DECIMAL(3,1) DEFAULT 2.0, teacher_id INT NOT NULL, capacity INT DEFAULT 60 COMMENT '课程容量', selected_count INT DEFAULT 0 COMMENT '已选人数', semester VARCHAR(20) NOT NULL COMMENT '学期，如2024-2025-1', schedule VARCHAR(100) COMMENT '上课时间地点' ); CREATE TABLE student_course ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, course_id INT NOT NULL, status VARCHAR(20) DEFAULT 'selected' COMMENT 'selected/withdrawn/finished', select_time DATETIME DEFAULT CURRENT_TIMESTAMP, regular_score DECIMAL(5,2) COMMENT '平时成绩', exam_score DECIMAL(5,2) COMMENT '考试成绩', total_score DECIMAL(5,2) COMMENT '总评成绩', grade_level VARCHAR(10) COMMENT '优秀/良好/中等/及格/不及格', UNIQUE KEY uk_student_course (student_id, course_id) ); CREATE TABLE tutor_student ( id INT PRIMARY KEY AUTO_INCREMENT, tutor_id INT NOT NULL COMMENT '导师ID，关联teacher表', student_id INT NOT NULL, bind_time DATETIME DEFAULT CURRENT_TIMESTAMP, status VARCHAR(20) DEFAULT 'active', UNIQUE KEY uk_tutor_student (tutor_id, student_id) );

有一个细节很关键：student_course表加的UNIQUE KEY uk_student_course (student_id, course_id)联合唯一索引，能在数据库层面阻止同一个学生重复选同一门课。就算后端代码有并发漏洞，数据库这层也能兜底，这在选课场景里非常重要。

4. 核心功能实现：选课、成绩评估、导师指导

4.1 Flask 项目目录结构：别在项目一开始就跑偏

我见过太多同学一上来就把所有接口塞到 app.py 一个文件里，最后文件上千行，连自己都找不到函数在哪。建议按这个结构组织 Flask 项目，从微信小程序请求到 Flask 路由的链路会更清晰：

student_system/ ├── app.py # 入口文件（也可以叫 run.py） ├── config.py # 配置文件 ├── requirements.txt ├── models/ │ ├── __init__.py │ ├── student.py │ ├── course.py │ └── tutor.py ├── api/ │ ├── __init__.py │ ├── auth.py # 登录、注册 │ ├── course_api.py # 课程列表、选课、退课 │ ├── score_api.py # 成绩查询、评估结果 │ ├── tutor_api.py # 导师绑定、指导记录 │ └── admin_api.py # 后台管理接口 ├── utils/ │ ├── __init__.py │ ├── jwt_utils.py # token 生成与校验 │ └── response.py # 统一返回格式 └── requirements.txt

Flask 的蓝图（Blueprint）机制一定要用。每个 api 文件里定义一个蓝图，app.py 里app.register_blueprint()注册一下，路由就自动挂上去了。小程序的请求路径就可以设计成/api/course/list、/api/course/select这种清晰结构。

4.2 小程序登录与 Token 鉴权：这套流程要刻在脑子里

微信小程序的登录设计和普通 Web 登录完全不同。它的核心逻辑是：

1. 前端调用wx.login()拿到一个临时 code（几分钟内有效）。
2. 前端把 code 发给 Flask 后端。
3. 后端拿着 code + 小程序的 appid + secret 去请求微信的jscode2session接口，换取 openid。
4. 后端正向判断 openid 是否已在 student 表中绑定，如果没绑定就让用户走学号绑定流程。
5. 绑定成功后，后端用 openid 生成一个自制的 token（可以用 JWT，也可以简单用itsdangerous或uuid），返回给前端。
6. 前端把 token 存到wx.setStorageSync('token')，后续所有需要登录的请求都在 header 里带Authorization: token。

这里要特别提醒：小程序端的 appid 和 secret 是敏感信息，千万不要放在小程序前端代码里。secret 只允许在后端使用。微信官方的开放接口校验方式也要注意，请求https://api.weixin.qq.com/sns/jscode2session需要配置正确的参数，返回的 openid 和 session_key 中，session_key 一般不需要存储，但如果要解密用户信息才需要用，毕设场景不做这个也行。

一个简单的 Flask 登录接口代码大致长这样：

@auth_bp.route('/login', methods=['POST']) def login(): data = request.get_json() code = data.get('code') # 调用微信接口换 openid（需要用 requests 库） url = ('https://api.weixin.qq.com/sns/jscode2session?' 'appid={}&secret={}&js_code={}&grant_type=authorization_code') resp = requests.get(url.format(appid, secret, code)).json() openid = resp.get('openid') if not openid: return jsonify({'code': 40001, 'msg': '登录失败'}) # 查找或创建用户... # 生成 token... return jsonify({'code': 0, 'data': {'token': token, 'user': user_info}})

code字段的命名容易和小程序返回的 code 混淆，建议后端接口的统一返回格式设计为{'code': 0, 'msg': 'ok', 'data': {}}，前端判断code === 0即可。

4.3 选课接口实现：事务、行锁和超选问题的解决思路

选课是这个系统里最核心、也最考验功底的一个接口。它的逻辑是：

1. 校验用户身份（token 解析）。
2. 校验课程是否存在、是否在选课时间窗口内。
3. 判断课程是否已满：if course.selected_count >= course.capacity: return 课程已满。
4. 开启数据库事务。
5. 插入 student_course 记录。
6. 更新 course 表的 selected_count +1。
7. 提交事务。

开始的时候你可能觉得这样写就够了。但要仔细想：如果两个学生同时选同一门课，假设容量只有 1 人，两个请求都通过了第 3 步的判断，然后一个插入成功，另一个插入因为数据库唯一索引报错了，那还算好。但如果你没有加唯一索引，就会出现"两个人都选上了，但课程容量只有 1"的情况，这就是超选。

在 MySQL 里，比较稳妥的做法是用SELECT ... FOR UPDATE对课程记录加行锁，锁住之后再检查容量、再插入选课记录。代码看起来是这样：

@course_bp.route('/select', methods=['POST']) def select_course(): user = get_current_user() course_id = request.json.get('course_id') # 开启事务 with db.session.begin(): # 锁定课程行 course = db.session.execute( 'SELECT * FROM course WHERE id = :id FOR UPDATE', {'id': course_id} ).fetchone() if course.selected_count >= course.capacity: return jsonify({'code': 40002, 'msg': '课程已满'}) # 检查是否重复选课（使用唯一索引兜底） existing = db.session.execute( 'SELECT id FROM student_course WHERE student_id = :sid AND course_id = :cid', {'sid': user['id'], 'cid': course_id} ).fetchone() if existing: return jsonify({'code': 40003, 'msg': '请勿重复选课'}) # 插入选课记录 + 更新课程人数 db.session.execute( 'INSERT INTO student_course (student_id, course_id, status) VALUES (:sid, :cid, "selected")', {'sid': user['id'], 'cid': course_id} ) db.session.execute( 'UPDATE course SET selected_count = selected_count + 1 WHERE id = :id', {'id': course_id} ) return jsonify({'code': 0, 'msg': '选课成功'})

如果平时用的是 SQLAlchemy ORM 而不是原生 SQL，那么对应的做法是with db.session.begin():包住所有数据库写操作，同时用db.session.execute执行带FOR UPDATE的语句。这里我不能把代码写得太死板，大家按自己的 ORM 习惯来，核心是"事务 + 行锁 + 唯一索引"这个思路。

关于选课时间窗口：可以在 course 表加select_start、select_end两个字段，接口里用datetime.now()判断当前是否在窗口期内。不在窗口期就提示"当前不在选课时间范围内"，这个功能点虽然简单，但能体现出系统的业务完整性，答辩时是个加分项。

4.4 成绩评估计算逻辑：权重可配置是亮点

成绩评估不能简单地"期末考了多少就是多少"。通常的规则是：总评成绩 = 平时成绩 × 平时权重 + 期末成绩 × 期末权重。比如平时占 30%，期末占 70%。有了总评之后，再按分数段映射到等级：

评估规则最好做成可配置的。我在 evaluation_rule 表里设计了权重字段和等级分数线字段。管理员在后台改权重，前端查询时动态读取，这样系统就不是写死的逻辑，而是可调整的规则引擎。虽然实现上只是多查一张表，但给人的整体感觉不一样。

计算接口的核心逻辑：

def calculate_total_score(regular, exam, rule): total = regular * rule.regular_weight + exam * rule.exam_weight if total >= rule.grade_a_line: level = '优秀' elif total >= rule.grade_b_line: level = '良好' # ... 以此类推 return round(total, 2), level

录入成绩的入口放在管理后台：管理员或任课老师选择一门课，看到选课学生列表，逐个填写平时分和期末分，保存时系统自动计算总评和等级，写回 student_course 表。前端小程序端只做成绩展示，不做录入，这样权限边界清晰，也避免学生自己改数据。

4.5 导师指导模块：绑定、记录、回复的完整实现

导师绑定可以由管理员在后台批量操作，也可以做成"学生申请-导师确认"的流程。毕设为了省事，先做成管理员分配即可，但如果开题报告里想体现完整度，建议做成申请流程。

实现步骤：

1. 管理员/导师绑定：管理员在后台为学生选择导师，写入 tutor_student 表。
2. 学生端查看导师：根据 token 中的 student_id，查 tutor_student 表拿到 tutor_id，再 join teacher 表拿到导师姓名、职称。
3. 导师端看学生列表：根据登录教师 id，查名下所有绑定学生。
4. 导师写指导记录：导师选中一个学生，填写指导内容，写入 guidance_record。
5. 学生查看指导记录：按时间倒序列出所有记录，未读的可做标记。

这个模块在代码层面不难，但要注意：指导记录需要做"导师只能写自己学生"的授权校验，不能允许导师傅传请求时带上别人的 student_id。可以写一个简单的校验函数：

def check_tutor_student(tutor_id, student_id): record = TutorStudent.query.filter_by( tutor_id=tutor_id, student_id=student_id, status='active' ).first() if not record: abort(403, description='该学生不是您的学生')

这种细节，评审老师如果问你"有没有做越权处理"，你就可以很自信地说有。

5. 常见问题与排查技巧实录

5.1 微信小程序端请求 Flask 接口失败的经典原因

这是毕设里踩坑最密集的地方，几乎每个做小程序 + 后端联调的人都遇到过。

报错场景：request:fail 或 timeout

常见原因有这么几个：

1. 开发者工具没有勾选"不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书"。开发阶段可以直接在开发者工具的"详情"→"本地设置"里勾上，否则真机预览时无法请求 HTTP 接口。
2. Flask 跑在127.0.0.1，而手机或开发者工具模拟器访问不到。Flask 服务启动时务必用app.run(host='0.0.0.0', port=5000)，让服务监听所有网卡。
3. 真机预览时，手机和电脑必须连同一个局域网，前端请求地址不能写 localhost，要写电脑的局域网 IP，形如http://192.168.x.x:5000。此时 Windows 防火墙可能拦截 5000 端口，需要在防火墙入站规则中放行。
4. 如果你用了requests去请求微信接口，要注意 Flask 的端口占用问题。5000 端口被占用时换个端口，比如app.run(port=5001)，前端请求的 URL 也要同步更新。

5.2 数据库中文乱码和"锁等待超时"问题

中文乱码通常是编码设置问题。建库时指定 utf8mb4，连接串里带上charset=utf8mb4，就基本不会出现这个情况。如果还乱，检查是否存在 INSERT 之前数据本身就已经是乱码的。

锁等待超时Lock wait timeout exceeded这个报错，多出现在选课接口高并发或事务忘记提交时。排查思路是：确认每条写操作是否都被事务包裹且能正常 commit/rollback；避免在一个事务内部执行耗时的外部 HTTP 请求（比如不要把微信接口调用放在事务里）；报错时用SHOW PROCESSLIST看看是否有卡住的连接。

5.3 成绩评估等级总是算不对？检查浮点数精度

DECIMAL(5,2)能保证数据库里的浮点运算相对稳定，但 Python 里0.3这种浮点数是有精度误差的。比如0.1 + 0.2不等于0.3，这就可能导致 59.999999 被判断成不及格。处理方式是：统一用Decimal或在比较时加上round()。我的习惯是计算完成之后先round(total, 2)再参与等级判断，避免这类边界问题。

5.4 微信开发者工具常见操作小坑

开发过程中有几个和工具使用相关的小细节，很多人第一次遇到会懵。

• 开发者工具显示"不在以下 request 合法域名列表中"：开发阶段按 5.1 的方法勾选跳过校验即可；发布上线则必须在小程序后台配置合法域名且必须 HTTPS。
• 页面无法加载，控制台报paused in debugger：这是开发者工具的调试断点问题，在 Sources 里取消断点或重启工具即可。
• 点击按钮没反应：优先检查bindtap写没写对。很多人会把bindtap="handleClick"错写成onClick或直接在标签里执行函数，小程序不支持这种写法。
• 单选框/复选框样式不生效：小程序原生 radio 组件的样式自定义比较受限，如果追求效果可以用label包裹自定义视图来实现，但毕设里用原生组件即可。

5.5 登录态失效和 401 一类权限问题

token 过期、前端没带 token、后端 JWT 解析失败，这三类问题都会导致接口鉴权失败。排查时先审查请求 header 里有没有Authorization字段，再用一个简单的测试接口验证 token 解析逻辑是否正常。建议后端封装一个@login_required装饰器，统一处理用户身份获取和鉴权失败返回，这样排查起来就方便许多。

5.6 关于"小程序违规、支付功能暂时无法使用"这类提示

这个热词背后反映的是很多小程序开发者会遇到的现实问题：微信小程序如果判定你的账号资质或类目有问题，会限制部分功能接口，包括支付。对于毕设项目，我不建议贸然接入真实微信支付，一个未认证的小程序无法开通对应支付权限是正常现象。如果选题确实涉及付费选课，可以在前端做"模拟支付"按钮，后端记录支付状态，文档里说明"生产环境可替换为微信支付 v3 接口"即可。这样既避开了资质问题，答辩时也能把流程讲清楚。

6. 系统扩展与优化建议

6.1 易忽略但很加分的附加功能

做完基础功能之后，如果还有富余时间，有包装价值的功能点值得考虑：

• 消息通知模块：导师写了指导记录后，学生端通过订阅消息收到提醒。微信小程序的订阅消息需要用户主动授权，每次授权一次性有效，但把这个功能写进文档会很有说服力。
• 成绩统计图表：学生端展示自己的成绩分布雷达图，导师端展示所带学生的整体及格率。ECharts 小程序版能实现。
• 学习预警：如果某学生连续两个学期出现不及格课程，系统自动给导师生成预警提醒。这个功能虽然在代码上只是多一个字段、多一条判断，但把"导师制"的业务意义拔高了很多。

6.2 部署上线路径的简要参考

毕设答辩时，项目能跑在云服务器上是个非常大的加分项。最简单可靠的部署方式是：买一台入门级云服务器，安装 MySQL、Python 3、pip 依赖，用gunicorn启动 Flask 应用，前端页面用 Nginx 反代。域名和 HTTPS 如果有条件就配，没条件的话小程序开发版只要勾选跳过校验也一样能联调。

这里提醒一点：上线前记得把 Flask 的debug=True关掉，设置好SECRET_KEY环境变量，数据库密码不要硬编码在代码里。这些安全习惯虽然不会直接体现在功能列表里，但一旦评委会问，你能回答上来就是加分项。

6.3 毕设论文结构的小建议

如果你这个标题是毕设选题，那论文的结构完全可以依据系统功能分成六章：

1. 绪论（背景、意义、国内外研究现状）
2. 相关技术介绍（Flask、小程序、MySQL、微信登录流程）
3. 系统分析（可行性分析、功能需求、业务流程）——这一章把导师制的闭环画清楚
4. 系统设计（总体架构、数据库设计、接口设计）
5. 系统实现（每个功能模块截图 + 核心代码讲解）
6. 系统测试（功能测试用例表 + 部分性能测试）

我最想强调的是第二章和第三章的互通性：技术介绍部分千万不要干巴巴写一堆基础概念，而是要结合你的系统说“本项目采用 Flask 作为后端框架，主要是因为它具备……，能够满足系统对于灵活路由与数据库操作的需求”。这样导师一眼就能看出来，你是真的动手做过，不是照着百度百科拼凑的。

个人感受与建议

这个题目看起来结构不复杂，选课系统、成绩评估、导师制三个功能也都是常见模块，但真正把这三个点串成一个闭环，其实比一开始想象中要费心。我自己的体会是，最大的难度不在 Flask 或小程序的语法上，而是业务边界的划分——导师能看什么、学生能改什么、管理员在什么时候介入，每一处都需要在数据库和接口层面做出约束。否则就会出现“学生能改成绩”“导师看不到自己学生”这类逻辑漏洞。

给想照着这个方向做毕设的同学一个最实际的建议：动手之前先花一个星期把数据库表设计好，把三个角色的权限矩阵用 Excel 列清楚，后面写接口会顺利很多。数据库一旦定了，整个项目的骨架就定了。

最后再分享一个小技巧：不管你最终选什么技术栈，一定要尽早做一次前端 + 后端 + 数据库的联调测试。我第一次做的时候，把小程序端写得差不多了才去连 Flask，结果发现返回的数据格式和前端预想的不一致，改起来非常痛苦。如果前期就定好返回格式、写成接口文档，后期基本就是无脑对接。这一点做到位了，整个毕设的进度会顺畅得多。