企业官网建设流程全解析

1. 为什么是"SpringBoot+Vue"这个组合

每年毕业季，都会有不少学弟学妹来问我同一个问题：毕设系统到底选什么技术栈最稳？我的回答一直很一致——如果你不是为了挑战高难度，而是想在有限时间内做出来一个能演示、能答辩、能放进简历的系统，SpringBoot + Vue 就是目前最不容易翻车的组合。

先聊聊后端。SpringBoot 最大的优势是"约定大于配置"，这意味着你不用像以前用 SSM 那样，花一个礼拜去折腾 XML 配置文件。SpringBoot 的自动配置机制帮你把大量重复性的配置都处理掉了，你只需要在 pom.xml 里加依赖、写一个 application.yml、然后直接开始写业务代码。另外，SpringBoot 的生态成熟到令人发指，你遇到任何问题，搜索一下基本都能找到答案。对毕设来说，"查得到资料"本身就是一种隐形评分项。

再聊前端。Vue 这个框架对初学者极其友好，渐进式的设计让你可以只把它当做一个简单的模板引擎来用，也可以逐步上手组件化、路由、状态管理。尤雨溪当年设计 Vue 的时候，核心目标之一就是"让更多人可以快速上手"，所以 Vue 的学习曲线比 React 平缓很多。对大部分还要同时应付考研、实习、毕业论文的计算机学生来说，用 Vue 写管理后台，配合 Element UI / Element Plus 组件库，几天时间就能搭出一个像模像样的界面。

再说教务管理系统这个选题。它不冷门、不会踩政策红线、老师对业务场景也熟悉，但更重要的是：这个系统的业务逻辑足够典型。管人、管课、管成绩、管权限，四个核心维度覆盖了绝大多数管理系统的共性需求。无论答辩老师问"你的系统解决了什么问题""你的数据库为什么这么设计"，还是问"这个功能怎么保证数据一致性"，你都能找到合理的、有深度的答案。做这个选题，你的精力可以重点花在"把技术做扎实"上，而不是花在"这个业务到底怎么定义"上。

当然，有的同学会问：这个选题是不是太常见了，答辩会不会因为撞题被压分？我的回答是：毕业设计评分看的是你做了什么、怎么做、你能不能讲清楚，而不是看你的题目有多冷门。同一道题目，有人做出来像培训机构的大作业，有人做出来像能上线的产品，差距全在执行过程。说到底，把教务管理系统做透，比做一个自己都讲不清楚的所谓"创新题目"要安全得多。

2. 教务管理系统到底在"管"什么：核心业务拆解

很多同学拿到这个题目，第一反应是打开画图工具，照着网上的截图开始画模块图。这个做法不是不行，但你得先想清楚一个问题：教务管理系统不是信息展示系统，它的核心是"流程"。

2.1 管人：角色权限怎么分

教务管理系统第一个要理清的是角色模型。最常见的划分是四种角色：管理员（一般是教务处的老师）、教师、学生，外加一个系统管理员负责系统配置。角色不清晰，后面的权限控制和页面设计全都会乱。

从数据模型上看，有两条路线可以走：一条是设计一张 user 表，用 role 字段区分身份；另一条是拆成 student 表、teacher 表、admin 表，再关联到 user 表。我个人的建议是走第二条路，为什么呢？因为学生有学号、班级、入学年份，教师有工号、职称、所属院系，这些属性差异很大。如果全部塞在同一张表里，会出现大量 NULL 字段，表结构会很臃肿。但是完全拆开也不行，因为登录验证的用户名、密码、角色这些公共信息应该统一管理。所以最合理的方案是：user 表存公共账号信息，student 表和 teacher 表通过 user_id 关联到 user 表，admin 可以直接用 user 表里加一个 type 字段区分。

这样做还有个实际好处：以后如果要加一个"家长"角色，只需要新建一张 parent 表关联 user 表，改动成本很低。答辩的时候老师问你 "为什么这么设计"，这就是一个很有说服力的切入点。

2.2 管课：选课业务的时序逻辑

选课是整个系统中业务逻辑最复杂、最容易出问题的一块。一次完整选课流程是这样的：管理员先录入课程基础信息（课程名、学分、授课教师、上课时间、教室），设置选课时间段和容量上限；学生在选课窗口期内进行选课操作；选课结束后，教师能看到自己课程的学生名单；成绩录入完毕后，学生可以查询成绩。

这里有一个非常关键的设计点：选课记录表怎么设计才能避免一个学生重复选同一门课？方案是在选课表中给 (student_id, course_id) 加联合唯一索引。这个索引在数据库层面兜底，哪怕前端按钮被连点两次、后端接受到两个并发请求，也不会产生重复记录。

课程的容量限制怎么处理？我建议在 course 表里保存一个选课人数上限字段，每次选课成功后对已选人数进行判断。这里要注意并发问题，后面我会专门讲事务处理。

2.3 管成绩：成绩的录入、修改与查询流程

成绩模块看起来简单，其实也有不少坑。成绩表的粒度问题——是把成绩字段直接放在选课记录里，还是单独建一张成绩表？我见过很多毕设把这俩混为一谈，最后写代码的时候各种别扭，但要讲清楚为什么分开。

我的建议是选课记录（student_course 表）与成绩在逻辑上分开，但物理上可以放在同一张表。也就是说，student_course 表除了 student_id、course_id、选课时间之外，再加一个 score 字段。当一个学生选了课，就插入一条记录，此时 score 为 NULL；教师录入成绩时，执行 UPDATE 填充这个字段。理由很简单：一个学生的课程成绩必然是针对"某学生选了某门课"这件事的，离开了选课记录，成绩就没有依附的实体。分开两张表建议在"可选课"和"已结课"是不同状态的时候再考虑。

教师的成绩录入权限也要控制：教师只能录入自己教的课程的成绩，而且最好在成绩录入时间窗口内可以修改、窗口结束后只能查看。这个逻辑可以通过判断当前时间和课程设置的时间窗口来实现，不难，但很体现细节。

2.4 业务闭环演示的价值

我想特意说一下"业务闭环"这件事。答辩的时候，老师让你演示系统，如果你只是机械地打开每个页面点一遍，效果其实很一般。优秀的演示方式是走一条完整的业务链路：管理员登录 -> 创建一门新课 -> 导入学生名单 -> 学生登录选课 -> 教师登录录入成绩 -> 学生查看成绩。

这种演示方式向老师传达了一个信息：你不仅做了页面，而且把业务逻辑打通了。这一点在评分中的权重，往往比 UI 做得炫酷更重要。

3. 数据库设计：最容易拉分的部分

开题报告写完，紧接着就是数据库设计。很多同学的数据库是"为了建表而建表"，表建了一大堆，关系却理不清。教务管理系统的数据库设计，如果做好了，答辩是加分项；做不好，老师随便问两句就能看出来你对系统理解不够。

3.1 核心表结构一览

先给出一套最基础的、经过验证的表结构方案，这套结构适合大多数教务管理系统：

• user 表：用户账号表，字段包括 id, username, password, role(枚举: student/teacher/admin), status(正常/锁定), create_time。
• student 表：学生信息表，字段包括 id, user_id(外键), student_no(学号), name, gender, class_id(外键), phone, email, enrollment_year。
• teacher 表：教师信息表，字段包括 id, user_id(外键), teacher_no(工号), name, gender, title(职称), department_id(外键), phone, email。
• department 表：院系表，字段包括 id, dept_name, dept_code。
• class 表：班级表，字段包括 id, class_name, department_id, grade_year。
• course 表：课程表，字段包括 id, course_no, course_name, credit, teacher_id, course_time, location, capacity, selected_count, status, select_start_time, select_end_time。
• student_course 表：选课记录表，字段包括 id, student_id, course_id, score, select_time，联合唯一索引 (student_id, course_id)。
• notice 表：公告表，字段包括 id, title, content, publisher_id, publish_time, is_top。

这套结构不算复杂，但覆盖了教务管理的所有核心业务。有几张表要特别说明：

department 表和 class 表要不要拆？我的答案是拆。很多偷懒的设计直接用一个字符串字段存"计算机学院2020级1班"，这会导致两个问题：一是想统计某个院系有多少学生的时候，只能用 LIKE 去模糊匹配，效率低且不准确；二是数据不规范，输入稍微不一致就查不到。拆成两张表，外键关联清晰，按院系统计、按年级筛选都变得非常简单。

3.2 逻辑删除与物理删除的选择

教务系统的用户数据、选课数据，都属于"删错了麻烦很大"的数据。以学生为例，一个学生因为休学暂时离校，管理员应该做的是把状态改为"休学"，而不是直接 DELETE。一旦物理删除，这个学生过去修过的课程、成绩记录也会失去关联。所以在设计时，user 表、student 表、course 表建议都加上 is_deleted 字段（0 表示正常，1 表示已删除），所有查询默认带上is_deleted = 0的条件。

有同学会问：那 MyBatis-Plus 的 @TableLogic 注解是不是更方便？确实方便，但我建议在毕设里手动处理 is_deleted 条件，原因后面讲后端的时候再展开。

3.3 索引与查询性能的基本功

毕设的数据量不会很大，但索引设计体现了你的数据库基本功。至少在以下几个场景建立索引：user 表的 username（登录时查询）、student 表的 student_no（按学号查）、teacher 表的 teacher_no、student_course 表的 (student_id, course_id) 联合唯一索引、course 表的 course_no。

还有一点是外键。我发现不少同学的建表 SQL 里根本没有外键，只有逻辑上的关联。从项目工程角度说，外键会影响插入和删除性能，生产环境里大量系统确实会放弃物理外键；但作为毕业设计，建议你还是建上物理外键。原因很现实：评委老师翻你的 SQL 脚本时，看到 FOREIGN KEY 会更认可你的基本功。你可以用逻辑外键来设计，但在文档和答辩时解释清楚为什么不用物理外键——这反而能体现思考深度。

3.4 数据字典与初始化数据

除了表结构，数据库设计文档里还应该包含一份完整的数据字典。每个表、每个字段的说明、类型、是否必填、是否主键外键。这块内容不复杂，但是实打实的得分项，而且也能让你自己写代码的时候少走回头路。

初始化数据同样重要：至少要有 2-3 个管理员账号、3-5 个教师账号、每个班放 10-20 个学生、每门课设置好选课时间窗口。没有数据的系统，演示的时候空空荡荡，老师看两眼就没兴趣了。我见过不少同学项目功能全开发完了，演示前才发现没有足够的测试数据，临时手工造数据浪费了大量时间。

4. SpringBoot 后端：从配置到接口，每一层都不能含糊

后端是整个系统的"大脑"。很多人的毕设项目，前端页面长得有模有样，一调接口就各种报错，问题往往出在后端的基础设计上——项目结构混乱、统一返回格式缺失、异常处理靠默认、权限拦截形同虚设。

4.1 项目分包结构

我推荐一个比较标准的 SpringBoot 分包方式：

com.example.education ├── controller // 控制层，只做参数接收和结果返回 ├── service // 业务层，核心逻辑 │ └── impl // 业务实现 ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 数据传输对象，用于前后端交互 ├── common // 通用类：统一返回结果、常量、工具类 ├── config // 配置类：跨域、拦截器注册等 ├── interceptor // 登录拦截器 └── exception // 全局异常处理

Controller 只负责接收参数、调用 service、返回结果，不写业务逻辑。业务逻辑放 service 层，数据操作放 mapper 层。这个分层原则，代码一多就能体会到好处：修改某个查询条件，不需要翻动 controller；调整业务规则，不会影响接口对外结构。答辩时老师问"你项目是怎么分层的"，你可以头头是道地讲出每一层的职责。

4.2 统一返回结果结构

我强烈建议你从一开始就定义好统一返回结构，而不是每个接口各返回各的格式。我的习惯是定义一个 Result 类，包含三个字段：code（状态码）、message（提示信息）、data（数据）。成功时 code 为 200，失败时按场景定义 400、401、500 等。

有了统一返回结构，前端 axios 的响应拦截器就可以做一个统一的处理：code 不是 200 时，直接弹出错误提示；code 是 200 时，返回 data 给业务代码。这样前端代码会非常干净，不需要每个页面都写一遍错误处理逻辑。

4.3 登录认证：拦截器 + JWT，够用又有深度

教务管理系统的登录认证，我推荐使用拦截器 + JWT 的方案。为什么不直接用 Spring Security？因为 Spring Security 对初学者来说太抽象了，配置一个东西绕来绕去，答辩时也很难解释清楚每一步是干嘛的。而拦截器 + JWT 的思路非常直观：用户登录成功后，后端签发一个 token；前端把 token 存在本地存储（localStorage）中；每次请求时在请求头加上 token；后端拦截器拦截需要登录的接口，校验 token 是否合法有效。

核心代码如下：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains("/auth/login")) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { response.setStatus(401); return false; } try { // 解析 token，验证签名和过期时间 Claims claims = JwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } }

还需要一个 WebMvcConfigurer 配置类来注册这个拦截器，并指定哪些路径放行、哪些路径拦截。一般静态资源、登录接口放行，其余接口统一拦截。

JWT 的库我用的是 jjwt，它的 API 比较简单，生成 token 和解析 token 各一个方法。JwtUtil 类里封装两个方法，一个根据用户 ID 和角色生成 token，设置过期时间比如 24 小时；另一个解析 token 返回 Claims。注意要在 application.yml 里配置一个 secret 密钥，密钥长度不要小于 32 字节，否则新版 jjwt 会直接报错。

JWT 方案在答辩中很容易讲清楚，而且可以展开聊"为什么用 JWT 而不是 Session"：因为 JWT 无状态，适合前后端分离部署，服务端不需要存储会话信息。这个点一提，评委就知道你搞懂了认证的本质。

4.4 跨域配置：前后端联调的第一道坎

前端跑在 8080 端口，后端跑在 8090 端口（或者 8081），浏览器默认会拦截这种跨端口请求。解决跨域有两种常见方式：一种是在后端配置 CORS，另一种是前端通过反向代理转发（Vue 的 devServer.proxy）。

我在项目里两种都做了：开发环境靠前端 proxy 转发，生产环境靠后端 CORS 配置兜底。后端配置方式是在 WebMvcConfigurer 里重写 addCorsMappings 方法，允许的前端地址设置成http://localhost:5173（Vite 默认端口），允许的请求头要包含 Authorization。

开发阶段遇到的 90% 的联调问题，不是接口写错了，而是跨域没配好。浏览器 F12 打开 Console，如果看到 CORS 字样开头的报错，先检查后端跨域配置，不要先去怀疑接口逻辑。

4.5 事务与并发：选课功能的核心难点

选课是系统里并发要求最高的场景。假设课程容量只剩 1 个名额，这个时候有 3 个学生同时点击选课，如果代码不做并发控制，就可能出现选课人数超过容量的情况。

一个看似正确的错误写法是这样：

public boolean selectCourse(Long studentId, Long courseId) { Course course = courseMapper.selectById(courseId); if (course.getSelectedCount() >= course.getCapacity()) { return false; // 已满 } course.setSelectedCount(course.getSelectedCount() + 1); courseMapper.updateById(course); studentCourseMapper.insert(...); return true; }

在单线程测试下这个逻辑完全正常，但并发场景下，两个请求同时读到 selectedCount=99，容量是 100，两个都判断"未满"，两个都执行了 update，最终 selectedCount 变成了 101。这就是典型的"超卖"问题。

解决办法是在查询时加上数据库层面的行锁。使用SELECT ... FOR UPDATE把课程记录锁住，使得同一时刻只有一个事务能修改这条记录。具体做法是在 CourseMapper 中写一个自定义方法：

@Select("SELECT * FROM course WHERE id = #{id} FOR UPDATE") Course selectByIdForUpdate(Long id);

然后在 service 层加上 @Transactional 注解，把"查课程 -> 判断容量 -> 更新人数 -> 插入选课记录"封装在同一个事务中。这样一来，当一个事务还没有提交时，另一个事务的 SELECT FOR UPDATE 会阻塞等待，从而避免超选。

答辩时老师如果问"你的系统怎么处理并发"，你一定要能说出这套锁和事务的逻辑，这在毕业设计中属于实打实的加分项。

4.6 SpringBoot 版本选择的血泪教训

相关热搜词里有一条"springboot版本太高"，这个我必须展开讲，因为我在不止一个学生的项目里踩过这个坑。

SpringBoot 3.x 要求 JDK 17 及以上，而很多学校的教学环境、机房电脑、或者学生自己的老电脑，装的是 JDK 8。如果你选了 SpringBoot 3.x，本地开发会直接遇到版本不兼容报错，哪怕你改了 JDK 版本，有些老旧的依赖、教程里的写法也可能失效。

最稳妥的方案：SpringBoot 2.7.x + JDK 8 + MyBatis-Plus 3.5.x + jjwt 0.9.x。这套组合经过大量毕业设计验证，兼容性最好，网上资料也最多。不要为了"用新版"而去用新版，毕业设计的核心是稳定跑通。

5. Vue 前端：从环境配置到页面流畅跑通

前端这块，很多同学的痛点不在"不会写代码"，而在"环境都没配好"。实话实说，Vue 项目的环境配置确实容易劝退新手，尤其是第一次接触 Node.js 生态的人，光是装个依赖就能卡一下午。

5.1 环境配置：一步错步步错

Vue 开发环境就三样东西：Node.js、npm（或 yarn/pnpm）、Vue CLI 或者 Vite。推荐直接用 Vite 创建项目，命令是：

npm create vite@latest education-ui -- --template vue

创建完之后进入项目目录，安装依赖：

npm install

关于网络问题，如果你在国内，npm 下载慢或者失败是正常的，不是你的电脑出了问题。解决办法是设置淘宝镜像源：

npm config set registry https://registry.npmmirror.com

设置完再跑 npm install，速度会有质的提升。很多同学在"vue安装依赖"这一步卡住，绝大多数就是源的问题。

5.2 路由与导航守卫：先把登录跳转做对

使用 Vue Router 时，最重要的不是把页面配出来，而是把"登录了才能访问""没登录跳回登录页"这套规则处理好。通过路由守卫实现：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.path === '/login') { next(); } else { if (!token) { next('/login'); } else { next(); } } });

另外可以根据角色做路由懒注册：管理员能看到"班级管理""院系统计"菜单，教师和学生不显示。具体做法是把菜单配置写在数据库或一个前端常量文件里，登录成功后根据角色动态过滤菜单项。这个功能做出来，"系统很高级"的感觉一下就上来了。

5.3 axios 封装：让接口调用变成顺手的事

裸用 axios 调接口是最低效的做法。强烈建议封装一个 request.js，做三件事：统一 baseURL（通过环境变量管理）、请求头自动带上 token、响应拦截统一处理错误码。

import axios from 'axios'; const request = axios.create({ baseURL: '/api', timeout: 10000 }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = 'Bearer ' + token; } return config; }); request.interceptors.response.use( response => { if (response.data.code === 200) { return response.data.data; } else { ElMessage.error(response.data.message); return Promise.reject(response.data); } }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); } ElMessage.error('请求失败，请稍后重试'); return Promise.reject(error); } ); export default request;

用这种封装方式，每个页面的接口调用代码会非常简洁：

const res = await request.get('/course/list', { params: { page: 1 } }); // res 已经是后端返回的业务数据，直接用即可

5.4 页面组织与组件复用

管理后台的页面千万别每个页面从头写。推荐的做法是：布局部分（侧边栏 + 顶栏 + 内容区）用一套公共 Layout，通过路由嵌套实现；表格和表单尽量抽取成公共组件，页面之间通过 props 传参。

比如学生管理页面和教师管理页面，从结构到逻辑都非常相似：表格展示、搜索栏筛选、新增弹窗、编辑弹窗、删除按钮。这种页面抽出一个通用"数据管理页"组件，传入表头配置、接口地址、搜索字段，两个页面各只需要几十行代码就能完成。

组件封装这一块，做得好不好，直接体现你的代码水平。评委老师问"你的代码有没有复用性"，这就是最好的回答。

5.5 改 bug 的常规思路

跑完整个项目，不可能一个 bug 都不出。我总结几个毕设期间最常见的报错："vue项目源码怎么发给别人"这个热词提示了一个典型情况——把 Vue 项目压缩包发给同学后，对方运行报模块找不到。原因就是 node_modules 目录没删。正确的交付方式是删掉项目里的 node_modules 目录再压缩，对方拿到后执行 npm install 重新安装依赖。

还有一种常见报错是页面白屏、控制台报各种 module not found。大概率是依赖没装全或者装错了版本，先执行 npm install，不行就把 node_modules 删掉重新装。如果还不行，检查是否安装了额外的组件库但没在 main.js 里注册。

6. 答辩稳过的三个细节与二次开发方向

功能做完了，不要直接交给老师等结果。答辩这个环节，很多同学不是死在功能不全，而是死在讲不清楚、演示不顺畅。

6.1 演示剧本：提前走一遍业务闭环

我上面提到过业务闭环演示，这里细化一下。演示前，建议写好一份"演示脚本"，包含：管理员账号、教师账号、学生账号各一个，提前准备一门没满的课程、一门满了的课程、一个未录入成绩的班级。

演示顺序建议是：先展示系统整体界面（花 30 秒介绍布局）；然后登录管理员账号，演示新增课程、查看选课情况；再退出登录，用学生账号选课、退选、查成绩；最后用教师账号录入成绩。整个流程走 3-5 分钟，老师对你的系统已经有了全面认知。

演示中最怕的是"临场翻车"——比如某个网络请求超时、某个弹窗报错。建议提前录制一份演示视频作为 backup，万一现场出问题，直接播放视频，比台上干等强得多。

6.2 答辩高频问题清单

把这些问题的回答提前准备好：

• 为什么用 SpringBoot？/ 为什么选 Vue？——从开发效率、前后端分离、生态成熟角度回答。
• JWT 和 Session 的区别是什么？——JWT 无状态、服务端不存 session、适合分布式。
• 选课并发你怎么处理的？——SELECT FOR UPDATE + 事务，说出思路即可。
• 数据库为什么这么设计？——从第三范式、业务数据原子性、扩展性回答。
• 项目有哪些不足？——这是一个陷阱题，不能回答"没有不足"，要说目前还缺什么、后续怎么改进。

6.3 二次扩展方向：给简历和毕设加分

基础功能做完之后，如果还有时间，我建议按优先级做这几个扩展：

第一，Redis 缓存。把课程列表、公告列表这些热点数据缓存到 Redis，后端写一个简单的缓存工具类，演示时对比一下加了缓存前后的响应速度——其实数据量小看不出明显差别，但架构意识有了。

第二，数据可视化。管理员首页做一个数据大屏，展示各院系学生人数、课程选课率、成绩分布等统计图表。前端可以用 ECharts，后端只需要提供聚合统计接口。这个功能做出来，视觉冲击力很强，评委对你的印象分会显著提升。

第三，在线选课冲突检测。学生选课时，如果选的课上课时间与已有的课冲突，系统拒绝选课。这个逻辑并不复杂：查询学生已选课程的 course_time，和新选的课程比对即可。但这个功能非常贴合实际教务场景，属于"业务完整性"层面的加分项。

6.4 文档与源码：毕业设计的最后一道工序

最后提醒一句：源码和文档是交付物，不是附件。数据库脚本要有建表语句 + 初始化数据，文档里要有需求分析、功能设计、数据库设计（含 E-R 图）、接口说明（建议用表格把每个接口的地址、参数、返回值列清楚）。项目 README 里写清楚：环境要求、启动步骤、默认账号密码。别小看这个 README，你自己过两个星期回来看项目，没有它也得重新摸索一遍。

我在实际带毕设项目的过程中体会很深的一点是：真正拉开分数差距的，从来不是某一个炫酷功能，而是整套系统能不能"完整地转起来"。与其花时间在一个很偏门的功能上死磕，不如把登录、授权、选课、成绩这条主链路打磨得干净、流畅，再把文档和源码整理清楚。这样你答辩的时候，底气是完全不一样的。

最后再分享一个小技巧：项目全部跑通之后，把所有核心功能录一个 8-10 分钟的演示视频，保存到网盘里。一方面是答辩备份，另一方面，这个视频在你后续找实习、写简历的时候，可以直接发给你未来的面试官看，比口头描述"我做了一个教务系统"有说服力得多。