企业官网建设流程全解析

学科竞赛管理平台这种题目，在毕业设计里算是一个"长盛不衰"的选题。每年都会有学生拿到类似的项目包——源码、数据库脚本、论文、部署文档全部配齐，看起来非常完整，但真正开始动手的时候，往往一头雾水：不知道代码从哪看起，不知道论文要写什么，更怕部署环节哪一步出问题导致整个系统跑不起来。

这篇文章我打算换个角度，不单纯讲"项目有什么功能"，而是以一套完整交付的 SpringBoot + Vue + MySQL 学科竞赛管理平台为例，从选题逻辑、模块拆解、数据库设计、后端实现、前端落地、部署文档写作、论文答辩准备一条龙讲清楚。你拿到任何同类项目，都能按照这条思路快速吃透并变成自己的东西。

1. 这个题目为什么值得做：选题逻辑与系统全景

1.1 学科竞赛管理中的常见痛点

先聊选题。毕设选题最怕什么？最怕题目"做出来容易，写论文难"，或者反过来"论文好写，代码草草了事"。学科竞赛管理平台属于典型的业务管理系统，业务逻辑清晰、角色分明、数据流转自然，非常适合用 SpringBoot + Vue + MySQL 这套主流技术栈来承载。

实际场景里，很多高校的学科竞赛管理仍然停留在"人工填表 + Excel 汇总 + 微信群里传文件"的阶段。学生报名要下载报名表，填完之后发到指定邮箱，负责老师再手动汇总名单；作品提交靠 U 盘拷贝或者网盘链接，命名不规范的情况天天都有；评审环节要么评委线下打分、纸质表格手写成绩，要么通过在线文档收集分数，谁都能看到谁的成绩，数据安全性很难保证。

这些痛点放到系统里，就对应着一个非常完整的业务闭环：管理员发布竞赛，学生在线报名并提交作品，评委登录后打分，系统自动汇总成绩，管理员审核后发布公示。整套流程覆盖了"信息发布—报名—材料提交—评审—成绩管理—公示通知"六个核心环节，每一个环节都能写出对应的功能模块，也都能在论文里作为业务分析的一部分去展开。

1.2 系统定位：从报名到评审的闭环

这套系统的价值在于把线下零散流程搬到了线上，统一了数据入口。管理员不需要再手动核对几十份报名表里有没有缺项，报名状态实时可查；学生不需要反复询问"老师我报上了吗"，系统里直接看到审核进度；评委不需要等待邮件附件，登录后按列表查看作品、提交分数。

从系统角色看，这套平台通常设计为三类角色：管理员、教师评委、学生。管理员负责竞赛管理、赛程设置、学生信息管理、评委分配和成绩审核；评委负责查看已经报名的参赛作品并打分；学生则完成注册登录、查看竞赛列表、在线报名、上传作品和查看自己的成绩。

这三个角色的权限边界清晰，映射到后端就是接口级别的权限控制，映射到前端就是路由权限和菜单展示的差异化。这也是为什么这个题目适合毕业设计——它的复杂度刚好在"能写清楚"和"有一定含金量"之间，不会像电商系统那样涉及太多交易、支付、库存并发等难题，也不会像纯工具类应用那样功能单薄、论文难凑篇幅。

2. 技术栈选型没有悬念，但落地顺序有讲究

2.1 三个核心组件各管什么

SpringBoot + Vue + MySQL 在毕业设计中的地位，差不多可以理解为"标准答案"。SpringBoot 负责后端接口，Vue 负责前端交互页面，MySQL 负责数据持久化。这套组合的学习资料极其丰富，遇到问题基本都能搜索到答案，对毕设来说，可用性和可维护性比技术的"新潮程度"更重要。

SpringBoot 简化了 Spring 的配置过程，内置 Tomcat，打 jar 包就能直接跑，不需要单独部署外部容器。项目里的 Controller、Service、Mapper 三层结构清晰，老湿们看代码时也很好顺着链路去检查逻辑。Vue 的优势是组件化开发，页面之间复用度高，配合 Element UI 这类组件库，后台管理系统的页面搭建速度非常快。MySQL 则是经典的关系型数据库，事务支持好，对于这种业务关系明确的系统非常合适。

有人会问：为什么不用前后端分离更彻底的方式？其实这个项目本身就是前后端分离的。前端独立项目通过 Axios 请求后端接口，后端不渲染 HTML 页面，只返回 JSON 数据。只不过在部署时，前端打包后的静态文件既可以用 Nginx 托管，也可以直接放进 SpringBoot 的静态资源目录，这一点后续在部署文档部分会细说。

2.2 建议的开发顺序：自下而上还是自上而下

拿到一套完整项目源码后，你先做什么？我强烈建议：不要直接打开 IDEA 就开始跑代码，而是先按照"数据库表结构 → 后端接口列表 → 前端页面结构"的顺序梳理一遍。

数据库表是系统的根基。打开数据库脚本文件，数一数有多少张表，每一张表是干什么的，表之间的主外键关系是什么，先建立一个整体印象。然后去后端代码里找 Controller，看暴露了哪些接口，记住这个顺序：Controller 只是入口，真正的逻辑在 Service 层，数据访问在 Mapper 层。最后打开前端代码，看页面路由、状态管理、接口封装，理解页面如何调用后端接口。

这套顺序也对应着你写论文的逻辑：需求分析之后，先做数据库设计，再画系统实现，最后讲测试和部署。不管是阅读别人的代码还是自己写代码，从数据模型入手永远是最稳的路径。如果你打算在拿到源码的基础上做二次开发，要在哪个模块加字段、加接口、加页面，也都在这个梳理过程中自然浮现出来了。

3. 核心功能模块怎么切：五个必须做扎实的模块

3.1 竞赛发布与赛程管理

第一个核心模块是竞赛发布。管理员创建竞赛时需要填写哪些信息？竞赛名称、竞赛级别 flag（校级/省级/国家级）、主办方、竞赛简介、报名开始时间、报名截止时间、作品提交截止时间、竞赛状态。注意"竞赛状态"这个字段不是用户手动填的，而是根据当前时间和报名时间自动对比得出的，比如待报名、报名中、评审中、已结束四种状态。

这里有一个细节很多人容易忽略：报名截止和作品提交截止往往是两个时间点。报名截止后，学生不能再提交新的报名申请，但已经报名成功的学生仍然可以在作品提交截止前上传或修改作品。如果系统里只有一个时间字段，这个场景就覆盖不了。所以竞赛表里至少要两个时间字段：报名截止时间和提交截止时间。

赛程管理还包括竞赛流程的可视化展示。前台页面展示竞赛列表时，学生希望一眼看清"我现在能不能报""材料什么时候交"，这就需要一个状态标识，根据服务器时间动态计算，而不是直接读数据库里填好的静态值。

3.2 学生报名与资格审查

报名模块容易写得很简单，也容易写得有深度。简单版就是学生填写个人信息，点击报名按钮，插入一条报名记录。有深度一点的版本至少要包含三块：去重校验、资格审核、报名状态流转。

去重校验非常关键。同一学生针对同一竞赛只能提交一次报名申请，如果后端不做校验，前端多点击几次按钮就会出现重复记录。后端校验方式就是在报名表中建立联合唯一索引，比如student_id和contest_id联合唯一，同时 Service 层再判断一次，双保险。

资格审核是管理员操作的。学生提交报名后，状态默认是"待审核"，管理员需要核对学生信息是否真实、是否具备参赛条件，然后通过或驳回。这里就出现了第一个"状态流转"的概念：待审核 → 已通过 / 已驳回。驳回时需要填驳回原因，这个原因要展示给学生看，方便学生修改信息后重新提交。

3.3 作品上传与材料管理

作品提交模块我认为是整个系统里最容易出 bug 的地方，因为涉及文件上传。

先说文件类型限制。竞赛作品可能是文档、压缩包、图片、视频。后端需要校验文件扩展名，同时校验文件大小，SpringBoot 默认的文件上传大小限制是 1MB，实际项目中一般要改成更大的值。可在配置文件中设置spring.servlet.multipart.max-file-size和max-request-size。

再说文件存储位置。很多毕设项目喜欢把文件传到项目目录下，比如指定一个 upload 文件夹，但这样部署后非常麻烦：第一，项目重新打包时会覆盖文件；第二，在多级目录下运行起来路径容易混乱；第三，tomcat 的工作目录和项目实际目录可能不一致。更稳妥的做法是上传到服务器上一个绝对路径下的固定目录，比如/home/contest/files/，然后在数据库里只保存文件的相对访问路径或访问 URL，由后端提供一个静态资源映射接口来访问这些文件。

3.4 评委打分与成绩汇总

评委模块的权限是限定的——一个评委只能看到自己被分配到的竞赛作品。管理员在分配评委时，把竞赛 ID 和评委用户 ID 关联起来，打分记录表里也要记录评委 ID。

评分规则通常分为：百分制总分、多个评分维度加权。比如一个竞赛有"创新性、完成度、展示效果"三个维度，分别占 40%、40%、20%，评委先给各个维度打分，系统自动加权计算总分。这个规则建表时就要设计好，是从一张评分规则表读取比例，还是直接把比例写死在代码里？建议写到后端配置或者数据库表中，避免评委已经打了一批分数之后，管理员想调整评分比例却发现代码里写死了，改动成本很大。

成绩汇总最怕的问题是重复计算。如果同一评委对同一作品多次提交了分数，是覆盖原记录还是新增记录？正常逻辑应该是：只允许一条有效记录，评委重新打分时 update 原记录。这也是评委打分模块的一个核心校验点。

成绩汇总的展示也有一些细节。学生端只能看自己的成绩，不能看别人成绩；管理员端可以看所有成绩；评委端可以看到自己打过分的记录。这些查询权限控制，在后端 Mapper 查询条件里就要写清楚，不能等到前端控制。

3.5 公告通知与消息触达

公告模块看似简单，真正做得好的系统会区分"平台公告"和"竞赛动态"。平台公告是管理员发布的通知，比如平台使用说明、账号注册须知；竞赛动态是和特定竞赛绑定的消息，比如报名延期提醒、作品命名格式要求。

这个模块的深度可以从两个方面提升。第一，公告发布时可以指定接收对象，比如"仅通知已报名某竞赛的学生"，这就涉及用户分组的场景；第二，公告阅读状态记录，哪些用户已读，哪些未读，需要一个中间关联表来维护。这两点写进论文里，都是很不错的业务细节亮点。

4. 数据库设计：这些表关系和字段最容易想错

4.1 六张核心表的关联关系

数据库设计是毕设论文里必须重点展开的部分。我梳理了一套比较规范的学科竞赛管理平台数据模型，核心六张表：用户表、竞赛表、报名表、作品表、评审表、公告表。

用户表sys_user：主键 id、用户名、密码、真实姓名、角色类型、职称、所属院系、联系电话、邮箱、创建时间。密码字段用 BCrypt 加密后存储，不能保存明文。

竞赛表contest：主键 id、名称、级别、主办方、简介、报名截止时间、提交截止时间、创建时间。

报名表registration：主键 id、学生用户 id、竞赛 id、报名时间、状态、驳回原因。student_id指向用户表，contest_id指向竞赛表，两个字段联合唯一。

作品表work_submission：主键 id、报名记录 id、作品名称、作品简介、文件路径、文件大小、提交时间、状态。作品表和报名表是一对一关系，一个报名记录对应一份作品信息，但作品内容可以更新。

评审表score_record：主键 id、竞赛 id、评委 id、作品 id、创新性得分、完成度得分、展示效果得分、总分、评审意见、评审时间。核心约束：同一评委对同一作品只能有一条记录。

公告表notice：主键 id、标题、内容、类型、关联竞赛 id、发布时间。

4.2 状态字段、时间字段和附件路径的设计教训

状态字段建议用字符串或小整数类型，不要用布尔类型的 0 和 1 去硬映射多种状态。比如报名状态，如果只用0/1表示"未审核/已通过"，那"已驳回"和"待审核"就无法区分。建议直接用tinyint存 0、1、2、3，在代码里用枚举或者常量类去映射，保证可读性。

时间字段统一用datetime，前端传时间字符串时注意时区问题。这是一个很经典的坑：前端传 "2025-05-20 18:00:00"，后端接收后存到 MySQL，页面再显示时发现少了 8 小时。原因是连接池配置中的时区参数没有指定，比如serverTimezone=Asia/Shanghai缺失。部署文档里必须把这个参数写出来。

附件路径字段，长度要给足。有人把文件路径字段设计成 VARCHAR(50)，结果存绝对路径直接报"Data too long"。建议最少 VARCHAR(255)，如果会放云存储 URL，可以到 VARCHAR(500)。

数据库设计还有一个重要实践：每张表都加上创建时间和更新时间字段。在开发调试时这两个字段能帮你定位很多数据问题，在论文里展示表设计时，这两个字段也让评审老师觉得设计考虑得很细致。

5. 后端SpringBoot实现要点：JWT登录、文件上传与分页

5.1 权限控制：三种角色一套JWT

这类管理系统的登录认证，基本上都用 JWT（JSON Web Token）方案。流程是：用户登录成功后，后端生成一个 token 返回给前端，前端把它存在本地，每次请求时放到请求头里，后端通过拦截器或过滤器校验 token 的合法性并解析出用户信息。

具体到实现，后端项目里通常会有一个拦截器，拦截需要登录的接口路径。在拦截器中，从请求头拿到 token，调用工具类验证签名是否有效、是否过期；如果有效，从 token 中解析出 userId 和 role；然后把用户信息放入请求上下文，供后续 Controller 使用。

角色权限的区分有两种做法。简单做法是针对不同角色的接口在路径上进行区分，比如/admin/**、/judge/**、/student/**，拦截器里面针对路径前缀做权限判断。这种做法简单直观，适合毕设。更灵活的做法是使用注解，在方法上标注需要的角色，拦截器里检查当前用户的角色是否符合要求。任选一种都可以，但要在论文里讲清楚自己的方案。

密码加密直接使用 Spring Security 中集成的 BCryptPasswordEncoder，不要自己写简单的 MD5。BCrypt 每次加密同一个密码结果都不同，因为内部加了随机盐，安全性远高于明文或简单哈希，而且用法很简单，就是一个加密方法加一个校验方法。

5.2 文件上传与存储路径

后端实现文件上传的核心逻辑并不复杂，真正需要想清楚的还是存储方案。我在前面提到过，推荐把文件存到服务器固定目录。

后端代码逻辑通常分为四步：第一步，校验文件为空；第二步，校验文件大小和扩展名；第三步，生成存储路径，一般按日期目录加随机文件名组织，避免文件名冲突；第四步，保存文件并返回访问路径。

文件名尽量不要用用户上传的原始文件名，因为可能出现中文、特殊字符、超长文件名等问题。建议生成 UUID 或时间戳加随机数作为存储文件名，原始文件名可以记录到数据库字段里展示用。

静态资源映射也很重要。如果采用本地存储，后端需要配置一个映射，把/upload/**路径映射到实际存储目录，这样前端访问文件的 URL 才能生效。很多同学部署完发现图片打不开，都是因为漏了这一步静态资源映射配置。

5.3 分页查询与条件筛选

管理后台的列表页基本都需要分页查询。使用 MyBatis-Plus 的话，分页写入非常简单，配置一个分页插件，然后调用page方法即可。条件查询则使用LambdaQueryWrapper动态拼装查询条件。

有一个工程实践上的建议：分页接口的参数建议包含当前页pageNum、每页大小pageSize、关键字keyword、状态status等，返回结果通常是一个包含总记录数和当前页数据的对象。前端拿到总记录数计算总页数，渲染分页组件时才能联动。

还有一种常见情况：列表需要连表查询，比如报名列表要显示竞赛名称和学生姓名，这就不能只查报名表了，需要在 XML 里写连表 SQL 或者用 VO 对象接收结果。建议在代码里单独定义 VO 类，比如RegistrationVO，字段包含报名表基本字段，再加上竞赛名称和学生姓名字段，Mapper 查出来的结果直接映射到 VO。这样既不影响实体类的纯洁性，又能满足前端展示的需求。

6. 前端Vue的落地细节：路由守卫、组件复用和状态管理

6.1 路由守卫把未登录用户挡在门外

前端页面通常分为：登录页、学生端页面、管理员端页面、评委端页面。不同角色看到不同的菜单和页面，最基础的拦截操作就是路由守卫。

在 Vue Router 中注册一个全局前置守卫，每次跳转路由前检查本地是否有 token。如果目标页面需要登录但没有 token，跳转到登录页；如果已经登录但访问登录页，跳转到首页。角色菜单的权限控制，则可以通过一个可变的侧边栏菜单列表来实现，后端登录接口返回用户信息和角色，前端根据角色动态生成菜单数组，实现不同角色看到不同功能入口的效果。

这种方案比把所有页面都注册好、仅靠路由守卫拦截更彻底——因为未授权页面连菜单入口都不显示，用户体验更好，代码也不复杂。

6.2 复用组件代替复制粘贴

Vue 的核心优势是组件复用。在学科竞赛管理系统里，复用率最高的三个组件分别是：竞赛信息卡片、报名状态标签、通用搜索表单。

竞赛信息卡片组件接收一个竞赛对象，展示竞赛名称、级别、时间、状态；报名状态标签组件根据状态值显示对应的颜色标签，比如待审核是橙色、已通过是绿色、已驳回是红色；通用搜索表单组件封装了关键字输入框、时间选择器、搜索和重置按钮，在不同列表页面配置不同字段即可复用。

组件复用不是"把页面拆得越碎越好"，而是把那些确实在多处出现、且展示逻辑一致的模块抽出来。拆分粒度太细反而会增加代码理解和维护的成本，这是一个需要拿捏的度。

6.3 表格、表单与上传组件的组合使用

后台管理系统页面基本离不开表格和表单。Element UI 里的el-table、el-form、el-upload这三个组件的搭配方案，几乎能覆盖管理平台的绝大多数场景。

表格列配置中，状态列建议用el-tag加上不同type属性展示颜色，时间列格式化、操作列放按钮组是固定套路。表单提交时，需要绑定rules校验规则，注意表单校验的触发时机，不要在表单还没渲染完成时就调用validate。上传组件el-upload的坑在于它默认使用 Ajax 上传，如果你希望在上传之前先处理业务逻辑，比如填充报名 ID，就需要自定义http-request方法。

前端还有一个很容易被忽略但很重要的工作：统一封装 Axios 请求。所有请求都走同一个实例，配置基础路径、超时时间、请求拦截器自动附加 token、响应拦截器统一处理 401 状态码跳转登录页。这样代码结构干净，排查接口异常时效率也高。

7. 部署文档要写到什么程度，答辩才不慌

7.1 环境清单与版本注意

部署文档的质量直接决定你复制项目之后能不能顺利跑起来，也决定你答辩时演示环境的稳定性。一套合格的部署文档，至少要覆盖以下内容：JDK 版本、Maven 版本、Node.js 版本、MySQL 版本、开发工具版本。

版本不一致是环境搭建时最容易卡住的原因。比如本机装了 JDK 17，项目是基于 JDK 8 写的，运行时报"Unsupported class file major version"；或者 Node.js 版本太高导致依赖安装失败。建议尽量按照部署文档中标注的版本去准备环境，除非你自己确认升级没有兼容问题。

MySQL 初始化时要注意编码配置。数据库连接 URL 需要携带useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai参数，不然中文会出现乱码，时间也会偏 8 小时。

7.2 本地启动步骤

本地运行如果分前后端两个目录，通常步骤是：先初始化数据库，导入 SQL 脚本；再启动后端，打包成 jar 后运行，或者直接在 IDEA 中运行；最后启动前端，在package.json所在目录执行依赖安装命令，然后执行开发模式启动命令，访问前端提供的本地 URL。

第一次启动时，建议先单独验证后端接口通不通：启动后端后，在浏览器访问一个公开接口或登录接口看返回结果；然后再启动前端，看页面能否正常登录。如果直接打开前端发现登录报错，优先检查后端是否启动成功、端口是否冲突、请求是否跨域。

端口冲突是很常见的问题。SpringBoot 默认端口是 8080，如果本机已经占用了这个端口，需要在配置文件中换一个，比如 8081。前端开发服务器默认是 5173 或 8080，根据工具版本不同而不同，跨域配置也需要对应调整。

7.3 常见启动失败场景

部署文档里最实用的是"常见问题排查"部分。写几个高频失败场景和处理方法，能省下大量时间。

第一个场景是数据库连接失败，报错提示Access denied for user，检查账号密码是否正确，权限是否授予。第二个场景是前端依赖安装失败，大概率是网络原因或 Node 版本问题，可以更换镜像源。第三个场景是后端打包失败，报编译错误，检查 JDK 版本和 Maven 依赖是否下载完整。第四个场景是页面数据加载不出来，打开浏览器控制台看接口返回状态码，401 未登录、404 接口不存在、500 服务端异常，分别对应不同排查方向。

还有一点值得强调：演示答辩时一定要准备备用启动方式。如果演示电脑上没有 IDEA，后端可以通过命令行mvn spring-boot:run启动，前端构建好静态文件直接放进 Nginx 或后端静态目录。这样即使场上环境有限制也能完成演示。这个经验，写进部署文档里会显得特别贴心，也是实际演示的保命技巧。

8. 论文和答辩：代码写完了，这才是重头戏

8.1 论文结构怎么安排

论文结构按照学校要求走，但大体逃不出这套主流骨架：摘要、绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。

绪论部分要交代研究背景和意义。重点是结合实际场景去写，不要空泛地说"信息化时代来临"。可以具体写：学科竞赛参与人数逐年增加、信息分散、报名和评审流程效率低等，这些和本系统功能一一对应的问题描述，是评审老师最愿意看到的内容。

需求分析部分必须包含功能需求和非功能需求。功能需求用用例图配合文字说明三个角色各自能做什么；非功能需求写系统性能要求、安全性要求、易用性要求。这里要注意：功能需求一定要和后续数据库设计和系统实现保持一一对应，不要需求分析里写了三个模块，实现章节里只讲了两个。

系统设计部分内容包括：系统总体架构图、功能模块图、数据库 E-R 图、表结构说明、核心流程时序图。这部分是论文的骨架，字数占比最大，也最需要花时间画图。数据库表结构表格要完整列出字段名、类型、长度、是否主键、是否允许为空、字段说明。

系统实现部分不需要把所有代码都贴进去，只需要针对每个核心功能模块，挑最关键的代码片段，配合界面截图来说明实现思路。每一张界面截图都要有对应的文字说明，说明这段话描述的是哪个功能，用户操作步骤是什么，数据如何流转。

8.2 答辩时容易被追问的六个问题

答辩环节里，评委老师的提问方向其实比较集中。我把高频问题整理了一下，按出现概率排序：

第一个问题是：系统为什么选择前后端分离架构，和传统的 JSP/SSH 方案相比有什么优势？这种题考的是技术选型意识，回答时侧重前端交互体验、后端职责分离、开发和部署灵活度。

第二个问题是：JWT 和 Session 认证有什么区别？为什么选择 JWT？这里要讲到无状态、适合前后端分离、扩展性好，同时也不回避 JWT 的缺点，比如 token 过期管理、无法主动注销等问题。

第三个问题是：数据库表之间的关系有哪些？举一个具体的例子说明。比如报名表中学生和竞赛是多对多关系，通过报名表实体化后变成一对多。表达出"多对多关系在关系数据库中需要中间表"这个概念就足够了。

第四个问题是：文件上传后存储在哪里？如果文件越来越多，磁盘满了怎么办？回答本地存储加定期备份的同时，可以提一句生产环境可以换用对象存储，体现思考深度。

第五个问题是：项目中有没有任何并发问题的处理？这时候可以用"同一竞赛学生重复报名"为例，讲联合唯一索引加后端校验的双保险方案。

第六个问题是：你自己完成了哪些部分？这是最常问也是最重要的问题。如果项目是参考现成的源码，你需要对每一部分都能说出设计思路和实现细节，千万不要只会说"这部分是参考模板的"。建议在答辩前，亲手把核心模块重写一遍，哪怕只是报名和打分两个模块，这个过程中你对该系统的理解深度会完全不一样。

9. 尾声：拿到项目之后先做这三件事

最后，我想分享一点个人经验。

很多同学拿到一套"源码+数据库+论文+部署文档"完整资源后，第一反应是赶紧跑起来看效果，然后放着不管，等到答辩前一周再拿出来。这个方式是很危险的。跑通只是第一步，你还需要做三件事才能真正把项目变成自己的。

第一，把数据库 SQL 文件里的建表语句自己敲一遍，不要用工具直接导入。敲的过程你会不由自主地思考字段的作用，这是建立数据模型认知最直接的方法。第二，找一个核心流程试着自己扩展一个小功能，比如给报名模块加一个"报名人数上限"的扩展字段和后端校验逻辑，真改过一次代码，你才能理解原有代码的调用关系。第三，把论文里的核心图表自己重画一遍。E-R 图、用例图、架构图、时序图，每张都亲手画一次，你才能在答辩时被人问到细节而对答如流。

做毕业设计，本质上不是"做一个项目给老师看"，而是"通过一个项目证明你具备独立完成一个软件系统的能力"。这套学科竞赛管理平台的完整交付物给了你一个不错的起点，剩下的深度消化和二次思考，还需要你自己沉下心去走。只要把前面这几个部分吃透，你拿到的就不仅仅是一套能运行的代码，而是一份能支撑你顺利答辩的底气和素材。