SpringBoot+Vue本科生交流培养管理平台：全栈开发实战解析

作为一个自己完整走过毕设全流程的人，我太清楚这个选题背后的纠结了——题目要足够撑得起工作量，技术栈要能写进简历，答辩的时候项目还得真能跑起来。今天想聊的这个“SpringBoot+Vue本科生交流培养管理平台”，恰好是这类需求里非常典型的代表：前端用Vue，后端用SpringBoot，数据库走MySQL，前后端分离，功能覆盖学生管理、导师指导、培养计划、学术交流、成果归档这些本科生培养阶段的核心业务。无论你是准备拿它做毕业设计、课程设计，还是纯粹想找个真实的Java Web项目练手学习的源码，这套东西都有足够的参考价值。

先说清楚这个项目到底能干什么。本科生培养过程中，导师、学生、教务管理员三方之间的信息传递经常是断裂的：开题报告散落在群里，讲座报名靠线下签到表，成果材料堆在网盘里，学分修读进度靠学生自己拿Excel统计。这个平台就是把“培养”这个抽象的概念，拆解成一条条具体的业务流程，通过线上化的方式串起来。从实用角度看，它并不是一个堆功能的花架子，而是一个贴近真实教务管理场景的业务系统，对于学习前后端分离开发、理解RBAC权限模型、掌握SpringBoot+Vue的全链路开发，都有很好的帮助。

接下来我不打算只贴源码，而是把这个项目从设计思路、模块拆解、核心代码逻辑到实际部署跑通的整个过程完整讲一遍。文中的所有技术方案都是基于我实际做过、测过、踩过坑之后沉淀下来的，希望对你做毕设或者学习SpringBoot+Vue开发有切实的参考价值。

1. 项目整体设计与功能拆解

1.1 项目定位与核心业务痛点

在动笔写代码之前，先得想明白一个问题：这个平台要解决什么？我见过不少学生的毕设项目，功能堆了一堆，但本质上就是增删改查的拼盘，答辩老师一问“你这个系统解决了一个什么业务问题”，就答不上来。这个本科生交流培养管理平台的定位其实很清晰，它聚焦的是高校本科生导师制培养过程中的几个核心痛点。

第一是师生沟通分散。导师带学生，交流记录散落在微信、邮件、QQ里，过程性材料没有统一归档的地方。第二是培养进度无法可视化管理。学生修了多少学分、当前处于开题还是中期阶段、任务截止日期是什么时候，这些信息如果不系统化，就只能靠人工翻记录。第三是学术活动信息不透明。讲座、沙龙、导学活动发个海报就结束了，报名人数、出勤情况、参与记录全靠手工统计。第四是成果管理混乱。论文、专利、竞赛获奖这些成果如果没系统录入，到综测加分或者学年评优的时候又得重新收集。

这个平台的业务设计就是围绕这四点展开的：以学生为主线，以导师为服务节点，以培养计划为目标导向，把学术交流、成果管理、通知公告作为过程支撑。你用这套逻辑去理解它的每个模块，就会发现没有哪个功能是多余的，每个页面都是业务闭环中的一环。

1.2 功能模块与角色权限梳理

整个项目的功能结构，按照业务域可以切成六大模块：用户管理、培养计划管理、学术交流管理、项目成果管理、通知公告管理、数据统计看板。其中用户管理是基础，其他各个模块都基于用户体系展开；数据统计看板属于锦上添花的部分。

角色方面，这个平台设计了三种主角色：管理员（通常是教务人员或辅导员）、导师、学生。三种角色各自管理的内容不一样：

这里的关键点是权限控制。很多初学者在做用户模块的时候，就是简单地在前端判断一下“如果是管理员就显示某个按钮”，这种做法在真实项目中是远远不够的。这个项目的做法是走Spring Security + JWT的路子，后端接口统一做权限校验，前端只负责控制页面元素的展示。这也是答辩时一个值得展开讲的亮点：你不只是实现了功能，你还理解了前后端权限控制的边界。

1.3 技术选型与架构思路解析

为什么用SpringBoot+Vue+MySQL这套组合，而不是SSH（Spring+Struts+Hibernate）或者JSP+Servlet？这个问题如果被问到，你最好能给出有深度的回答。

SpringBoot的意义在于降低了Spring家族的使用门槛。传统的Spring项目，XML配置能写到手软，建立项目的过程本身就劝退新人。SpringBoot通过自动配置、Starter机制、内嵌Tomcat，让一个Java后端项目从创建到启动只需要几分钟。而且它的生态极其成熟，对接Spring Security、MyBatis-Plus、Redis这些常用组件都有现成的Starter，这对学生的毕设项目来说，意味着你可以把更多精力投入业务逻辑，而不是环境配置。

Vue在前后端分离的架构下，优势体现在组件化和响应式数据绑定上。Vue的单文件组件把HTML、CSS、JavaScript写在一个.vue文件里，结构清晰，维护起来舒服；数据双向绑定让表单操作和列表渲染变得非常直观。Vue还有成熟的中后台UI库，比如Element UI，表格、表单、弹窗、分页这些后台管理系统里高频出现的组件都是现成的，写前端页面效率能翻好几倍。

MySQL作为关系型数据库，对于这类业务结构清晰、数据关系明确的管理系统，是最稳妥的选择。事务支持完善，SQL查询灵活，主流的云服务商都提供托管实例，部署也方便。虽然有人建议上PostgreSQL或者MongoDB，但客观说，在毕设和课设的场景里，MySQL的生态和参考资料是最丰富的，遇到问题搜索一下很快就能找到答案。

架构上，前后端分离是这个项目的核心思路。后端提供RESTful API，前端通过Axios发起HTTP请求进行数据交互。开发阶段，前端使用Vue CLI的devServer做代理，解决跨域问题；生产阶段，前端构建成静态资源文件，由Nginx托管，后端打成Jar包独立运行。这套架构的好处很实在：前后端可以并行开发、通过接口文档对接，代码耦合度低，将来扩展新功能也更灵活。

2. 核心模块实现要点与代码视角

2.1 用户登录与JWT鉴权机制

用户管理模块是所有业务系统的入口，登录认证做的质量直接决定了项目答辩时的整体印象。现在做Java Web项目，如果还在用Session+Cookie的方式管理登录态，技术上不能说错，但在前后端分离的架构下显然不是最优解。这个项目用的是JWT（JSON Web Token）方案。

JWT的核心思路是：用户登录成功后，服务端签发一个经过签名加密的Token字符串返回给前端，前端把这个Token保存下来，之后每次请求都在HTTP Header里带上它。服务端通过验证Token的签名来确认用户身份，整个过程不需要在服务端保存Session，天然适合分布式部署和无状态API。

我当年在这个环节踩过一个坑，就是密钥长度不够导致启动报错。后来整理代码时，对JWT工具类做了规范化处理，核心逻辑大致是这样的：

java复制public class JwtUtil {

    // 注意：实际项目中这个密钥不要写死在代码里，建议放在配置文件或环境变量中
    private static final String SECRET_KEY = "your-256-bit-secret-key-change-it-in-production";
    private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000L; // Token有效期24小时

    public static String generateToken(String username, String role) {
        return Jwts.builder()
                .setSubject(username)
                .claim("role", role)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME))
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
                .compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET_KEY)
                .parseClaimsJws(token)
                .getBody();
    }
}

有了Token生成和解析的工具类之后，还需要一个拦截器负责统一的认证校验。这里可以通过SpringBoot的HandlerInterceptor实现，核心逻辑很直接：拿到请求头里的Authorization字段，解析Token，如果解析失败或者Token过期，直接返回401状态码，业务接口就不用重复写认证逻辑了。

拦截器配置完成后，还需要配合Spring Security做细粒度的权限控制。常见做法是在拦截器里解析出用户角色，再通过注解或代码判断接口的访问权限。举例来说，发布讲座通知的接口只允许管理员调用，学生提交成果的接口只允许学生身份访问，这些规则可以统一收敛在一个权限判断的地方，而不是散落在各个Controller里。

提示：很多人初学Spring Security时会被它绕晕，建议你把重点放在理解“认证链”和“过滤链”的概念上，暂不需要深入源码。能讲清楚JWT的执行流程，已经是一个不错的加分项。

2.2 培养计划管理模块的设计逻辑

培养计划是本科生导师制管理的业务主线。这部分的难点不在于增删改查，而在于表结构设计与状态流转控制。

从业务角度看，培养计划分为两级：一级是“培养方案”，由管理员制定，定义了学生在校期间不同时间节点需要完成的事项，比如第1学期进行导师双向选择、第3学期完成开题报告、第5学期进行中期检查、第8学期提交毕业论文。二级是“学生培养实例”，即每个学生基于同一个个培养方案产生的一份具体执行计划，里面记录了该学生每个节点的完成状态、提交材料、导师评语等信息。

表结构设计上，我的做法是拆成四张表：

• train_plan：培养方案主表，存储方案名称、适用年级、创建时间
• train_node：培养节点表，存储方案的各个节点，包括节点名称、顺序号、默认截止时间
• student_plan：学生培养记录表，关联学生ID和培养方案ID
• student_node_record：学生节点完成记录表，关联学生ID和节点ID，存储提交材料路径、状态、导师审核意见

这套设计的关键在于把“方案定义”和“方案执行”分离开来。管理员调整培养方案不会影响已经生成的单个学生记录，学生提交材料时只更新自己的节点记录。用生活化的比喻就是：培养方案是做菜的菜谱，学生培养记录是按菜谱实际做出来的菜，菜谱改了不影响已经出锅的菜，但下一次做菜就会按照新菜谱来。

状态流转方面，每个节点记录有四种状态：待提交、待审核、已通过、已驳回。学生提交材料后状态变为待审核，导师审核通过后变为已通过，驳回则回到待提交并附带修改意见。这个状态机逻辑不复杂，但写代码的时候一定要注意并发问题，避免学生重复提交导致状态覆盖。建议在提交接口里加一个状态校验，只有当前状态为待提交或已驳回时才允许更新。

2.3 学术交流活动模块的实现思路

学术交流模块解决的痛点是信息发布和参与记录管理。业务场景是这样的：管理员（或导师）发布一个讲座通知，写明时间、地点、主题、报名截止时间，学生登录系统后可以看到活动列表并在线报名，到活动现场扫码或输入签到码完成签到，活动结束后系统自动生成参与记录。

实现上比较有意思的点有两个。第一个是“报名防重复”处理。学生点击报名时，后端要先查一下报名表，确认该学生没有报名过这个活动，然后再执行插入操作。这里我建议给报名表加一个唯一索引，字段是(activity_id, student_id)，双保险防止并发请求下产生重复报名记录。

第二个是签到码的设计。现场签到的实现方式有很多，二维码扫码、GPS定位、签到码输入，对于毕设项目来说签到码输入是性价比最高的方案。活动发布时管理员可以设定一个随机签到码，到场后由主持人公布，学生在系统中输入签到码完成签到。设计的时候要注意过期时间，活动结束2小时后签到码自动失效，这也算是一个真实业务规则的体现。

前端在活动报名这个页面上，推荐做一个“已报名/未报名”的区分。如果当前用户已经报名，按钮置灰并显示“已报名”；已经结束的活动，按钮换成“查看详情”。这个细节虽然不起眼，但很能体现用户体验的意识，尤其是在答辩演示的时候，评审老师会注意到这种交互逻辑。

2.4 成果管理模块与数据统计

成果管理模块解决的是学生项目成果的录入与审核问题。学生可以提交论文、竞赛获奖、专利、软著等不同类型的成果，录入基本信息并上传附件，导师审核后归档。这里有一个业务细节值得注意：不同类型成果的字段差异较大，比如论文需要期刊名称、影响因子，竞赛需要赛事名称、获奖等级，如果做一张大宽表，冗余字段会很多；如果每个类型都建一张表，查询又麻烦。

我的做法是主表加扩展表的方式：成果主表保存标题、类型、所属学生、状态、时间这些通用字段，再根据不同类型建扩展表存特有字段。查询列表时只查主表，需要看详情时再根据类型关联扩展表。这个方案在数据量不大的场景下完全够用，而且代码实现也不算复杂。

数据统计看板可以说是这个项目的“门面”。用ECharts实现各类柱状图、饼图、折线图，展示的内容可以根据业务来选。我当时做的是这几个维度：各年级学生培养进度分布、学术活动参与人数趋势、成果类型占比、导师指导学生数量排名。后端只需要提供统计接口，返回聚合好的JSON数据，前端负责渲染图表。

统计接口的SQL是另一个容易翻车的地方，尤其是涉及多个表关联聚合的时候。建议先在Navicat里把SQL调通再写Mapper，不要直接在代码里调试SQL。举个例子，统计各类型成果占比，SQL大致是这样：

sql复制SELECT type, COUNT(*) AS count
FROM achievement
GROUP BY type;

看起来简单，但如果achievement表里混入了未审核的数据，统计结果就会和实际不符。所以统计接口要记得加过滤条件，比如只统计状态为“已通过”的成果。

3. 环境搭建与项目落地实战

3.1 本地开发环境准备清单

这个部分是给刚准备动手的同学看的。有不少人拿到源码之后，第一件事不是看项目结构，而是急着启动，结果一上来就报错。我建议你先把环境准备好，再开始折腾代码。

需要安装的工具和版本选择如下：

关于JDK版本，我个人的建议是JDK 8或者11最稳妥。SpringBoot 2.x对JDK 8的支持非常成熟，网上能搜到的资料也最多。你如果非要用JDK 17，就得上SpringBoot 3.x，而SpringBoot 3.x在部分旧版依赖上会出现兼容性问题，反而增加了不必要的负担。

Node.js版本这个问题，我踩过两次坑。一次是Node 18下安装某个旧版本Vue CLI依赖时报了OpenSSL错误，另一次是新版Node上node-sass安装失败。所以别追新，稳定才是王道。前端项目建议直接用Vue CLI创建，版本是Vue 2.6 + Element UI 2.15，这套组合经过了大规模验证，踩坑的资料最多。

3.2 后端项目初始化与核心配置

拿到源码之后先别急着跑，花十分钟看一下项目结构。标准的SpringBoot项目按层分包：controller、service、mapper（或dao）、entity、config、utils。如果你看到有人把所有代码都写在一个包下面，那这个项目的质量就要打个问号了。

后端启动前必改的配置在application.yml里。数据库连接、端口号、文件上传路径，这三样是最容易出问题的。

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/undergraduate_platform?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: your-password
  servlet:
    multipart:
      max-file-size: 50MB
      max-request-size: 100MB

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

这几个配置项背后的逻辑值得说一下。characterEncoding=utf8保证中文不乱码，serverTimezone=Asia/Shanghai解决MySQL 8.0时区报错问题，useSSL=false是为了消除本地连接时SSL证书的告警。map-underscore-to-camel-case开启后，数据库下划线字段自动映射到Java驼峰属性，写代码时能省掉很多@TableField注解。

需要注意的是password字段用的是你自己的MySQL密码，如果记不清了建议先在Navicat里确认能连上数据库，再来配置项目。

3.3 前端项目结构与Vue核心配置

前端的项目结构主要分三块：src/api放接口请求封装，src/router放路由配置，src/views放页面组件。如果你拿到的源码里没有把接口请求统一收敛到api目录，而是直接在组件里写axios.get，那这个项目即使功能没问题，结构上也打了折扣。

接口请求封装的核心在于统一处理Token和错误状态。我通常会在request.js里创建一个Axios实例，配置baseURL和拦截器：

javascript复制import axios from 'axios'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

// 请求拦截器：自动携带Token
request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers['Authorization'] = 'Bearer ' + token
  }
  return config
})

// 响应拦截器：统一处理401等错误
request.interceptors.response.use(
  response => response.data,
  error => {
    if (error.response && error.response.status === 401) {
      localStorage.removeItem('token')
      window.location.href = '/login'
    }
    return Promise.reject(error)
  }
)

export default request

这里用baseURL: '/api'而不是直接写http://localhost:8080，是因为开发环境可以通过Vue的devServer.proxy做代理，生产环境由Nginx做路径转发，前端代码完全不用改，这个设计在前后端分离项目中很常用。

路由配置方面的重点是权限控制。登录之后根据用户角色动态生成可访问的路由，或者通过路由守卫在跳转前校验角色。路由守卫是Vue前端权限控制的核心，写法不复杂，但能体现你对权限设计的理解深度。

3.4 数据库初始化与联调启动

数据库初始化这一步，通常拿到源码时会附带一个.sql文件。进去之后先检查编码，再执行导入。如果执行过程中报错，九成是两件事：一是创建的数据库使用了默认的latin1编码，二是编码声明与MySQL版本不兼容导致。

我的习惯是先手动建库再执行SQL：

sql复制CREATE DATABASE undergraduate_platform DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
USE undergraduate_platform;
source D:/path/to/init.sql;

为什么要用utf8mb4而不是utf8，这一点值得说透。MySQL里的utf8实际上最多支持3字节的字符，遇到emoji或者生僻字就直接报错或乱码；utf8mb4是真正的4字节UTF-8，向下兼容utf8。在新生姓名、活动标题这些字段里，说不准就会遇到特殊字符，直接用utf8mb4是最稳妥的选择。

前后端联调启动时也有顺序讲究。先启动MySQL服务，确认数据库连接正常；再启动后端SpringBoot项目，看到“Started Application”日志说明后端起来了；最后启动前端npm run dev，浏览器访问前端地址。如果后端启动失败，不要急着查前端，先把后端日志看明白再说。

提示：后端启动如果报数据库连接失败，先检查MySQL服务是否启动、账号密码是否正确、数据库是否创建成功。90%的启动失败都是这三个原因，别一上来就去翻代码。

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

4.1 前端联调阶段的典型故障

前端最常见的报错是跨域问题。浏览器控制台会报错：Access to XMLHttpRequest at 'http://localhost:8080/api/login' from origin 'http://localhost:5173' has been blocked by CORS policy。这个报错看着吓人，其实解决方案就两个：开发环境配置代理，生产环境配置Nginx。

开发环境代理的方式更优雅，也符合实际项目的开发习惯。在vue.config.js里配置：

js复制module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

这个配置的意思是：前端请求/api/login时，Vue开发服务器会把请求转发到http://localhost:8080/api/login，浏览器看到的还是同源的请求，自然不会触发跨域拦截。这样就在不修改后端代码的情况下解决了跨域。

另外一种报错是“404”或者“页面空白”。如果你使用的是Vue Router的history模式，本地开发还好，但部署到Nginx后刷新页面会出现404。原因是路由是前端的，但浏览器刷新时会把路径发给Nginx，Nginx找不到对应的静态文件就返回404。解决方案是在Nginx配置里加一行try_files $uri $uri/ /index.html;，把所有请求都指向前端入口文件。

初次接触这个问题的同学容易一头雾水，这里我把它拆开解释：Nginx收到请求后，先看磁盘上有没有这个路径对应的文件，有就直接返回；没有就回退到index.html，交给Vue Router根据当前地址匹配路由。一解释你就明白为什么history模式必须要配这一行了。

4.2 后端启动与运行阶段的常见报错

后端启动阶段的报错，排查思路有个基本顺序：先看控制台最后几行错误信息，是连接数据库失败，还是端口占用，再对症解决。

端口占用是常见场景。上次启动的SpringBoot进程没关干净，再启动时就会报“Web server failed to start. Port 8080 was already in use”。解决方式是在命令行执行：

bash复制netstat -ano | findstr 8080

然后用taskkill /PID 对应的进程号 /F结束占用进程。Mac环境用lsof -i :8080查看。这一个操作虽然基础，但很多人卡在这里半天。

MySQL连接时报Public Key Retrieval is not allowed也是高频问题，根源是MySQL 8.0的caching_sha2_password认证插件。解决方案有两条：一是在JDBC连接串中加allowPublicKeyRetrieval=true，二是把MySQL用户认证方式改回mysql_native_password。本地开发前者更省事，但需要注意这个参数在直连数据库时确实存在一点安全风险，所以只建议开发环境使用。

时区问题也是MySQL 8.0换了时区处理方式后冒出来的。报错信息是Server returns invalid timezone，配置serverTimezone=Asia/Shanghai就成了标准解法。

另外我在实际使用中还遇到过中文乱码的情况，主要是Linux服务器上MySQL默认编码不是utf8mb4导致的。排查方式是进入MySQL执行SHOW VARIABLES LIKE 'character_set%'，看是不是utf8，如果不是，需要修改MySQL配置文件my.cnf中的character-set-server=utf8mb4。

4.3 部署上线阶段的坑与经验

本地跑通了，部署到服务器总会冒出各种新问题。最常见的坑是前后端部署在同一台服务器上，Nginx配置出错导致接口无法访问。

部署方案通常是这样：前端打包生成dist目录，由Nginx托管；后端打包成jar包，用java -jar命令运行。Nginx配置的核心段如下：

nginx复制server {
    listen 80;
    server_name your-domain.com;

    # 前端静态资源
    root /var/www/html;
    index index.html;

    # 后端接口转发
    location /api/ {
        proxy_pass http://localhost:8080/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 前端路由回退
    location / {
        try_files $uri $uri/ /index.html;
    }
}

这里的location /api/是把前端发起的/api请求转发给后端服务。proxy_pass后面写http://localhost:8080/api/还是http://localhost:8080，很多人搞不清楚，区别在于是否保留原请求的URI路径。如果写http://localhost:8080，转发后的路径就是/api/login；如果写http://localhost:8080/api/，由于Nginx在location /api/里已经匹配了/api/前缀，转发路径同样会是/api/login。两种写法都能通，但写错一个字符就会导致404或者路径重复。

部署时还有一件容易被忽略的事：Java后端使用的JVM内存设置。默认情况下，服务器会按物理内存的1/4来分配堆内存。512MB的小服务器上跑起来会非常吃力。建议使用java -jar -Xms256m -Xmx512m app.jar限制堆内存大小，让部署更为稳妥。

索引和数据库备份也建议顺手做了。至少给achievement表按student_id加上索引，给activity_registration表加上唯一索引。MySQL数据备份执行一次mysqldump，把产物存一份到本地，养成这个习惯是对自己项目负责。

4.4 问题排查速查表

最后，把上面这些高频问题整理成一个速查表，方便你实际开发时对照使用：

这张表我在实际给学弟学妹做指导时反复用过，你把它保存下来，遇到问题先对照着排查一遍，能省下不少瞎折腾的时间。

5. 用这个项目学到的底层逻辑与扩展方向

项目跑通只是第一步，更值得琢磨的是这个项目背后折射出的业务理解深度。本科生交流培养管理平台看着是一个典型的“管理系统”，但它和普通的“图书管理系统”“仓库管理系统”有一个本质区别：它的核心不是数据的存储与展示，而是流程的串联与状态的流转。学生的培养过程包含若干节点，每个节点包含提交、审核、驳回、通过的状态变化，不同角色在流程的不同阶段介入操作。这种“带状态的业务流”是很多真实企业应用的核心形态，触类旁通之后，你会发现进销存、工单系统、审批系统本质上都遵循同一套模式。

所以我不建议拿到源码就只满足于“跑通了”“改个名字交作业”。你在复用这个项目的同时，可以把以下三个点深入地想一想，它们会让你的项目答辩更有底气：

第一，如果业务量大了，Token无状态认证遇到需要强制下线某个用户的需求，该怎么处理？这就涉及JWT的扩展方案，比如引入Redis维护Token黑名单。

第二，如果你现在用MyBatis-Plus写Mapper层的逻辑，那你是否理解“逻辑删除”和“物理删除”的取舍？这个项目里采用了逻辑删除字段，那你是否清楚它在查询时自动追加了过滤条件？

第三，前端路由权限控制与后端接口权限校验的关系。前端控制是体验问题，后端控制才是安全问题，你能不能清晰讲出两者各自负责的部分？

这些都是面试或答辩时容易被追问的方向。如果你在完成项目的基础上，还能主动思考这几个问题，那这套源码对你的价值，就远远超出了“完成一个毕设”本身。从一个过来人的经验看，真正把人拉开差距的，往往就是这种在动手之外多想一步的习惯。希望这篇整理能帮你少走几步弯路，把精力投入到真正值得投入的地方去。